We have had that for 15+ years even in C with fine grained looping like OpenMP. It’s terribly inefficient to communicate across threads. Sometimes you just need SIMD

OMP is supposed to support SIMD/GPU offloading theses days. Not sure how good it is though.

oh, sorry. I grew up on the connection machine. in that era we did have implicit SIMD languages and I thought they were great

I support that effort. In the meantime, we have to do what we have to do. I'm presently in the process of optimizing some stuff and comparing the improvements of SIMD vs GPU on both ARM and x86 (this isn't that impressive, it's some basic loop vectorization). But just as Linus writes in that post, getting the compiler to do well seems impossible.

I'm measuring performance improvement and energy consumption reduction. The results are incredible. We really have to do this stuff. But it's complicated and the documentation is generally awful. So yes, a new language that deals with all of this would be very, very welcome :)

Star Lisp!

Although any functional or HPC language like Chapel will do.

... like intel ISPC.

Spoiler alert: it is a C dialect.

Or HLSL. Can use ISPC as an intermediary language.

This won't help, most uses of AVX or NEON have nothing to do with parallel processing of a bunch of numbers

How will these languages emit machine code for every variant of GPU/CPU/DSP/Vector/FPGA/whatever architecture they might run on? This isn't as simple as it sounds.

The host binary will include intermediate representation of the compute code to be compiled by the device driver. This already exists, see SYCL + SPIR-V. Intel's oneAPI is one implementation of this approach.

no, these are really big and interesting back ends. still, socially, that has to be better than _everyone_ breaking out the datasheets...if they even have those anymore