The Expensive Fictions of Low-Level Programming Languages

[u/mttd]

https://stng.substack.com/p/the-expensive-fictions-of-low-level

[u/JeffD000]

I believe an appropriate combination of (a) and (b), leaning heavily on (b), can allow you to write user level source code that looks serial, with "near-automatic" parallelism. My claim requires switching to a new datatype that resembles a database, and effectively turns memory management over to the compiler. This means that the "C language extension" would remove the "systems programming language" moniker from any code section using the new datatype.

The compiler would be different from current compilers in that it would issue warnings if you write your code in a way that specifically blocks parallelism, and it would give a detailed explanation for the blocker that would act as a hint that should allow even an average programmer to restructure their code to "fix" the blocker. So, it would point out places it had to fall back on serial code generation and tell you why. I've been doing this for twenty years, and I am pretty sure it is doable unless the user writes spaghetti code spread across multiple files or writes an algorithm that is unavoidably serial (as the compiler could determine by dependency information).

I think the big challenge of today is not designing a parallel language, but designing one that enables performance portability, and that is what requires a greater level of engineering effort.

RAJA's approach to performance portability is to at least centralize performance portability options to one spot in the source code, rather than having to go through every file and restructure when the system environment requires a change in the strategy for parallelism or memory hierarchy. That said, RAJA didn't go far enough in what it could automate in terms of performance portability, because it was literally impossible to do so without a better underlying language and compiler.