4 ms·

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

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.

AgentOrange1234 4y ago
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.)
- flohofwoe 4y ago
  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_array_list.zig https://github.com/ziglang/zig/blob/master/lib/std/multi_arr...
  - AgentOrange1234 4y ago
    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.
    - hansvm 4y ago
      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).
deleted 4y ago
[deleted]

AgentOrange1234 4y ago

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.)

flohofwoe 4y ago
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_array_list.zig https://github.com/ziglang/zig/blob/master/lib/std/multi_arr...
- AgentOrange1234 4y ago
  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.
  - hansvm 4y ago
    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).

deleted 4y ago

[deleted]