Compilers really shouldn't do this under the hood, it adds more complexity to the compiler, which makes it also more likely that things break in unexpected ways.

Instead these should be explicit programming language features (like defining a regular struct but then slice this struct into an SoA).

The rest should be handled by debugging and profiling tools which need to be much better integrated into the programming workflow than what is common today.

Huh. But putting the complexity into the compiler once, instead of into every application where we would need to manually fuse loops, etc., seems like a huge win for net complexity and readability?

(I’m sympathetic to the concern of things breaking in unexpected ways.)

You can design the language to make such transforms more transparent without resorting to special 'compiler optimization magic'.

For instance Zig has a MultiArrayList container in its stdlib which slices its generic item type into one array for each struct item. This isn't a special compiler feature, but a regular usage of Zig's comptime stuff:

https://github.com/ziglang/zig/blob/master/lib/std/multi_arr...

Yeah! And there is definitely value in certain domains for having predictable performance.

On the other hand, giving up that control and designing languages where more automatic optimizations are possible also seems really great. A lot of programming shouldn’t be concerned with low level perf anymore.

That's a really hard thing for a compiler to predict though. I recently got a 2x performance boost just by switching to an array of struct of array representation (making the cache lines have more data that actually matters), and the only reason it made a difference was the access pattern of a mildly non-trivial algorithm acting on that data (not hard per se, but definitely hard for a compiler to optimize through).

>> I really want compilers to be able to make these changes.

> Compilers really shouldn't do this under the hood, it adds more complexity to the compiler [...] Instead [...] like [...] SoA

Curious. I read GP as "I really want to be able to tell compilers to make these changes", but with exception of your SoA example, all (5) responses assumed it was a desire for a sufficiently magical black-box optimizer. Which in retrospect seems plausible, but first seemed to me quite odd. Of course you want to be able to slap in a paragraph of Halide, or annotate with memory organization... <puzzled expression>. Too much time thinking metaprogramming open compilers and inline multilingualism.

There's a long history of compilers attempting such "smarter" optimizations - with (metaphorically) "...and it flew straight into the mountainside" results.

I don't blame the compiler guys. They have to deal with tortuously complex real-world code. Sight unseen. And that code may only work correctly because of some unwritten assumptions, side-effects, and undefined behaviors, which no good program would ever rely upon.

GCC already has flags for various "dangerous" optimisation options (ffast-math for instance), there's no reason you couldn't have similar options that are disabled by default.

Very difficult to do + even more difficult to get right + seldom used ==> proposed feature is a low priority for the compiler team.

Please no, no extreme changes to what I've or others have written, I want to be able to get at least a reasonable idea of the performance some code will have in some particular context by looking at the code itself.

Stop trying to be as lazy as possible in such a bad way. Making compilers make up for a lack of programming ability is a mistake.

Once we solve the halting problem, we’ll easily reorganize arrays of structure into structures of arrays based on likely data access patterns.

Our intuition says that our code is full of opportunities like this and a "sufficiently smart compiler" ought to be able to work wonders with our code.

Our intuitions are wrong. In reality it takes a shockingly small problem to break these optimizations and make them do something in violation of the semantics of the language, and as a result, the compiler can't perform the optimization even if it is smart enough to try. Many, many, many compilers have tried. It is not a new idea, it is one that has been tried and failed over and over again.

This is one of the reasons why the functional programming crew advocate so hard for simpler semantics like pervasively immutable variables. The idea is that if the program's semantics promise less, the optimizations ought to be a lot easier. And at least at the surface level this is arguably true; Haskell does quite significant map (rather than "loop") fusion successfully. However, to date, the "sufficiently smart compiler" has not manifested to the extent that we'd like, the one that turns functional code into 2x - 3x faster code than imperative code. Generally the real-world smart compilers are straining just to keep up with C, as long as you write in a particular subset of the language.

I have quoted the term "sufficiently smart compiler" because if you want to dig further in, it is a good search term.

Many of our intuitions about our code are similarly broken. There was a lot of hope for exploiting "implicit paralellization" in our codebases; surely, our brains thought, there's just a ton of things in every code base that can be automatically turned into parallel code. That turned out to be false. There was a paper that took some representative code bases and extracted out the theoretical maximum parallelization that could even be done by any conceivable compiler optimization by analyzing the data dependencies themselves and it turned out to be shockingly small, thus effectively killing the idea. This story has been repeated a lot; another search term you can play with is "supercompiler", which amounts to "compilers are pretty good at optimizations in the small, surely our code bases are rife with opportunities to optimize at much higher levels across packages or the entire code base?" to which the answer to date has amounted to "No, not really."

In my opinion, the only hope for any of these ideas is someone sitting down and designing a language from the very get-go intended to work with these ideas. However, given the amount of experience necessary to do that and the subtlety of the task, I'm not sure that I'm not specifying a super-human degree of work by saying that.