4 ms·

This is true today, but I don't see that it must always be so. I'm not a compiler researcher, but isn't there a realistic chance that good things could happen i

This is true today, but I don't see that it must always be so. I'm not a compiler researcher, but isn't there a realistic chance that good things could happen if this became a major research focus? Somewhat related: I believe Jonathan Blow's currently unreleased Jai programming language is meant to do some interesting new things in this area, enabling (or rather, greatly simplifying) automatic transformations relating to memory layouts.

garethrowlands 5y ago
It's not going to happen for C.
username90 5y ago
> But isn't there a realistic chance that good things could happen if this became a major research focus? It has already been a major research focus the past 50 years or so. We have made great strides, yes, but we are still very far from where it needs to be to compete with lower level languages.
gnuvince 5y ago
The compiler can automate some things (take a look at Zig's MultiArrayList for example), but ultimately the programmer must understand the data in their application, how it needs to be transformed, and how to lay it out to be processed efficiently by the hardware. The compiler is a tool, you can set the field to help it do its job, but it's no magic wand, it cannot think and understand your application: only you can do that.
- MaxBarraclough 5y ago
  > take a look at Zig's MultiArrayList for example Thanks, I'd not seen that before, very neat. [0] I thought it was just going to be an option to be row-major or column-major, but no: Instead of storing a single list of items, MultiArrayList stores separate lists for each field of the struct. Could this be done in C++, perhaps with template metaprogramming? > The compiler is a tool, you can set the field to help it do its job, but it's no magic wand A paraphrasing of a familiar Mike Acton quote. Fittingly it was mentioned in a blog post that mentions the Jai language. [1][2] I find it frustratingly insubstantial. Given we all presumably accept Rice's theorem and how it applies to compiler optimization, it's a rather empty quip, especially considering we're discussing future possibilities. Today's compilers are capable of some impressive optimizations. It doesn't do to just dismiss the idea that tomorrow's compilers might be able to do significantly more with memory layouts. Consider if, decades ago, a sceptic of optimizing compilers had said: Compilers are useful tools, but they are not magic wands, and cannot achieve highly optimized instruction-selection and register-allocation. It cannot think and understand your application: only you can do that. The baseless suggestion that efficient register-allocation is impossible in the absence of a strong AI, would seem laughable today. > it cannot think and understand your application: only you can do that. Today's compilers are not strong AIs, sure enough, but that doesn't speak to the point here. Optimizers and static-analysis tools are capable of reasoning about program behaviour. Again, you haven't justified dismissing the suggestion that future optimizing compilers might be much more sophisticated at this kind of transformation. Perhaps I'm an optimist for arguing for the sufficiently smart compiler, but it doesn't strike me as beyond the realm of possibility. Perhaps the closer answer is to adjust (or indeed replace) our languages to be more amenable to memory layout transformations than C/C++. This would presumably be comparatively easy to implement. [0] https://ziglang.org/documentation/master/std/#std;MultiArrayList https://ziglang.org/documentation/master/std/#std;MultiArray... [1] https://blog.royalsloth.eu/posts/the-compiler-will-optimize-that-away/ https://blog.royalsloth.eu/posts/the-compiler-will-optimize-... [2] https://news.ycombinator.com/item?id=27010965 https://news.ycombinator.com/item?id=27010965
hsn915 5y ago
Jon's language is not about the compiler being smart and fixing your code. It's about letting the programmer write good code without the compiler getting in the way. I'm not aware of anything in his language that would make it easy for the compiler to automatically decide a better memory layout. It's rather the opposite: preventing the compiler from doing such things. For example, struct layout is always the order that you declare. There's no "feature" in his language that would re-order struct fields to minimize padding or anything like that.
- MaxBarraclough 5y ago
  All good points. To put that another way then, it's aiming to introduce language features which make it much easier for the programmer to transform their data layouts. gnuvince mentioned that the Zig language seems to be making inroads here too: https://ziglang.org/documentation/master/std/#std;MultiArrayList https://ziglang.org/documentation/master/std/#std;MultiArray...
  - kristoff_it 5y ago
    The important point about Zig's implementation is that this is all userland code. No extra syntax was added to the language to enable it, which is a great display of how flexible comptime can be.
    - MaxBarraclough 5y ago
      Very cool, Zig must have some powerful compile-time introspection facilities. > this is all userland code I imagine you meant library code here?
      - kristoff_it 5y ago
        I meant to say code that isn't part of the compiler or special cased in any way. So, yes, code that could very well be a normal third party library.

garethrowlands 5y ago

It's not going to happen for C.

username90 5y ago

> But isn't there a realistic chance that good things could happen if this became a major research focus? It has already been a major research focus the past 50 years or so. We have made great strides, yes, but we are still very far from where it needs to be to compete with lower level languages.

gnuvince 5y ago

The compiler can automate some things (take a look at Zig's MultiArrayList for example), but ultimately the programmer must understand the data in their application, how it needs to be transformed, and how to lay it out to be processed efficiently by the hardware. The compiler is a tool, you can set the field to help it do its job, but it's no magic wand, it cannot think and understand your application: only you can do that.

MaxBarraclough 5y ago
> take a look at Zig's MultiArrayList for example Thanks, I'd not seen that before, very neat. [0] I thought it was just going to be an option to be row-major or column-major, but no: Instead of storing a single list of items, MultiArrayList stores separate lists for each field of the struct. Could this be done in C++, perhaps with template metaprogramming? > The compiler is a tool, you can set the field to help it do its job, but it's no magic wand A paraphrasing of a familiar Mike Acton quote. Fittingly it was mentioned in a blog post that mentions the Jai language. [1][2] I find it frustratingly insubstantial. Given we all presumably accept Rice's theorem and how it applies to compiler optimization, it's a rather empty quip, especially considering we're discussing future possibilities. Today's compilers are capable of some impressive optimizations. It doesn't do to just dismiss the idea that tomorrow's compilers might be able to do significantly more with memory layouts. Consider if, decades ago, a sceptic of optimizing compilers had said: Compilers are useful tools, but they are not magic wands, and cannot achieve highly optimized instruction-selection and register-allocation. It cannot think and understand your application: only you can do that. The baseless suggestion that efficient register-allocation is impossible in the absence of a strong AI, would seem laughable today. > it cannot think and understand your application: only you can do that. Today's compilers are not strong AIs, sure enough, but that doesn't speak to the point here. Optimizers and static-analysis tools are capable of reasoning about program behaviour. Again, you haven't justified dismissing the suggestion that future optimizing compilers might be much more sophisticated at this kind of transformation. Perhaps I'm an optimist for arguing for the sufficiently smart compiler, but it doesn't strike me as beyond the realm of possibility. Perhaps the closer answer is to adjust (or indeed replace) our languages to be more amenable to memory layout transformations than C/C++. This would presumably be comparatively easy to implement. [0] https://ziglang.org/documentation/master/std/#std;MultiArrayList https://ziglang.org/documentation/master/std/#std;MultiArray... [1] https://blog.royalsloth.eu/posts/the-compiler-will-optimize-that-away/ https://blog.royalsloth.eu/posts/the-compiler-will-optimize-... [2] https://news.ycombinator.com/item?id=27010965 https://news.ycombinator.com/item?id=27010965

hsn915 5y ago

Jon's language is not about the compiler being smart and fixing your code. It's about letting the programmer write good code without the compiler getting in the way. I'm not aware of anything in his language that would make it easy for the compiler to automatically decide a better memory layout. It's rather the opposite: preventing the compiler from doing such things. For example, struct layout is always the order that you declare. There's no "feature" in his language that would re-order struct fields to minimize padding or anything like that.

MaxBarraclough 5y ago
All good points. To put that another way then, it's aiming to introduce language features which make it much easier for the programmer to transform their data layouts. gnuvince mentioned that the Zig language seems to be making inroads here too: https://ziglang.org/documentation/master/std/#std;MultiArrayList https://ziglang.org/documentation/master/std/#std;MultiArray...
- kristoff_it 5y ago
  The important point about Zig's implementation is that this is all userland code. No extra syntax was added to the language to enable it, which is a great display of how flexible comptime can be.
  - MaxBarraclough 5y ago
    Very cool, Zig must have some powerful compile-time introspection facilities. > this is all userland code I imagine you meant library code here?
    - kristoff_it 5y ago
      I meant to say code that isn't part of the compiler or special cased in any way. So, yes, code that could very well be a normal third party library.