4 ms·

“Programming languages are old, therefore they will never take advantage of our hardware.” Have you looked at how compilers have changed the past 30 years? How

“Programming languages are old, therefore they will never take advantage of our hardware.” Have you looked at how compilers have changed the past 30 years? How they take advantage of SIMD? AVX? The LLVM-revolution? It’s delusional to think compilers will never be smart enough to vectorise object-oriented code, which is the main gripe of this article.

astrange 5y ago
This article is about transforming memory layouts, which compilers don't do. GCC has some really really basic support for it which never works. Autovectorizing doesn't transform memory layouts, which is part of the reason it doesn't work that well either.
- moonchild 5y ago
  The sad part is chris lattner (llvm author)'s phd dissertation was on that exact topic. And yet nothing seems to have come of it since despite llvm's hegemony. (https://llvm.org/pubs/2005-05-04-LattnerPHDThesis.html https://llvm.org/pubs/2005-05-04-LattnerPHDThesis.html)
SuchAnonMuchWow 5y ago
No, the main gripe of this article is data locality, not vectorization. Those two are completely orthogonal and complementary: you can have data locality without vectorization and vectorization without data locality, and both bring performance improvements. But vectorization bring a constant speedup (from x2 to maybe x16 depending on the ISA of the processor), but data locality can improve performance much more because memory accesses are thousands of times slower than processor cycles. But if the semantic of your programming languages doesn't allow your compiler to change the layout of your data in memory, then there is almost nothing the compiler can do to improve data locality in your application.
- barrkel 5y ago
  Struct of arrays layouts does put you in a good position to apply vectorization techniques though. The article is rather more about columnar vs row formats for program entities than it is about locality generally. Columnar databases often use vectorized evaluation strategies because it's low-hanging fruit.
  - zaphar 5y ago
    The impetus for using a columnar format is precisely to get data locality. It is absolutely about data locality generally. You wouldn't take his approach at all if you didn't get the locality with it's associated performance improvements. It would be strictly more work for no gain. Locality is the entire point.

astrange 5y ago

This article is about transforming memory layouts, which compilers don't do. GCC has some really really basic support for it which never works. Autovectorizing doesn't transform memory layouts, which is part of the reason it doesn't work that well either.

moonchild 5y ago
The sad part is chris lattner (llvm author)'s phd dissertation was on that exact topic. And yet nothing seems to have come of it since despite llvm's hegemony. (https://llvm.org/pubs/2005-05-04-LattnerPHDThesis.html https://llvm.org/pubs/2005-05-04-LattnerPHDThesis.html)

SuchAnonMuchWow 5y ago

No, the main gripe of this article is data locality, not vectorization. Those two are completely orthogonal and complementary: you can have data locality without vectorization and vectorization without data locality, and both bring performance improvements. But vectorization bring a constant speedup (from x2 to maybe x16 depending on the ISA of the processor), but data locality can improve performance much more because memory accesses are thousands of times slower than processor cycles. But if the semantic of your programming languages doesn't allow your compiler to change the layout of your data in memory, then there is almost nothing the compiler can do to improve data locality in your application.

barrkel 5y ago
Struct of arrays layouts does put you in a good position to apply vectorization techniques though. The article is rather more about columnar vs row formats for program entities than it is about locality generally. Columnar databases often use vectorized evaluation strategies because it's low-hanging fruit.
- zaphar 5y ago
  The impetus for using a columnar format is precisely to get data locality. It is absolutely about data locality generally. You wouldn't take his approach at all if you didn't get the locality with it's associated performance improvements. It would be strictly more work for no gain. Locality is the entire point.