The problem is not so bad if the compilers explain themselves. I run g++ or gcc with --ftree-vectorize-verbose=3. So even if gcc wasnt able to vectorize a loop I get to see which one it failed on and why. This is very valuable and you can often tweak the code to fix the problem. It saves me the trouble of writing intrinsics by hand. A "sufficiently smart programmer" could do better, but they are rare too.

I would also like better feedback from compilers, and not just in the form of messages. It seems that throughout most of history compilers have been traditionally "one-way", i.e. you give them source and they produce a binary. To assist with code generation, what they should really be doing is some sort of "decompiling" of their optimiser's output back into e.g. C, maybe even with comments, so you can get an idea of what high-level optimisations it performed and where.

Just for the off hand chance that you are unaware of this, the option -fdump-tree-optimized on GCC and the other -fdump-tree.* options will do some of what you are asking for.

GCC isnt hipster hot nowadays but it has quite a few nice things. For C++ templates I still prefer G++ error messages over Clang++'s. I find the former a lot more informative, but without Clang breathing down their neck I doubt if they would have improved their error messages.

You can't actually compile the output of -fdump-tree-optimized, so it's close but not quite exactly what I had in mind.

Actually the problem is that compilers have dropped the ball on optimizing data representation. They generally don't even try.

Some faint glimpses of light can be seen, like compressed references in HotSpot or this Halide.

Rust and Go have nothing planned in this area.

Not entirely. In Rust, the runtime representation of enums (tagged unions) is left deliberately unspecified in order to allow for arbitrary optimizations depending on shape.

For example, The Option type in Rust (a.k.a. the Maybe type in Haskell) is a tagged union defined like this: [1]

  enum Option<T> {
      None,
      Some(T)
  }

Now say I use this like so:

  let foo = Some(6);

The runtime represenation of `foo` will be as follows:

  struct FooRepresentation {
      discriminator: u8,
      value: int
  }

...where `discriminator` is the field that determines whether the value is `None` or `Some`, and in the latter case `value` will contain the associated data.

But let's say I declare foo a bit differently, using a pointer to a value rather than a raw value:

  let foo = Some(~6);  // the tilde denotes a unique pointer

Now the runtime representation of `foo` is only a single pointer, and in order to determine if `foo` is `None` it just checks to see if the pointer is null. Rust is smart enough to perform this optimization on any tagged union with two variants where only one of the variants has associated data, and the type of that variant is a pointer.

On the flipside, if you want to guarantee a specific data layout then you can use a struct, which have the same layout rules as structs in C.

[1] https://github.com/mozilla/rust/blob/master/src/libstd/optio...

Not go or rust, but I'm curious, in ocaml or haskell, I imagine it is not easy to change data representation without refactorings, because of the widespread pattern matching? e.g. in ocaml: let (x,y) = point;;

That's one of the reasons why record types are recommended instead of tuples. They don't cost anything at runtime but make it harder to shoot yourself in the foot.

> and then we're programming in assembly again. (Or perhaps C++.)

Is that so bad? The reason we're in JS in the first place in those environments isn't because it's the best language for the job, it's because it's the only language that can be used in that environment.

If you can have the best of both worlds, why not?