By: Jörn Engel (joern.delete@this.purestorage.com), May 21, 2022 1:23 pm
Room: Moderated Discussions
Jan Wassenberg (jan.wassenberg.delete@this.gmail.com) on May 20, 2022 10:12 pm wrote:
>
> To expand on this a bit, I believe omp simd has a (near-)total lack of operations that cannot
> be expressed as C++ operators. By contrast, Highway provides about 100 such ops:
>
> https://github.com/google/highway/blob/master/g3doc/quick_reference.md#operations
There is a lot of value in abstractions. Instead of writing code in Assembler, we created languages like C. We now write code against the abstraction and let compilers map from the abstraction to appropriate assembly language. That concept worked well enough that we still a language designed for a PDP-11 even though most of us never saw a PDP-11 in our lifetime. The abstraction continues to work for CPUs designed decades after the abstraction.
Not all abstractions are equally good. You could argue that C aged better than Fortran or Cobol. Or if you dislike C, it is much harder to avoid than Fortran or Cobol.
There is also a lot of value in an abstraction for vector programming. Again, not all abstractions are equally good. And the problems are quite similar, you want something generic enough to cover all sorts of difference CPUs. And you want good enough performance when translated to actual CPUs that people don't resort to Assember or Intel intrinsics.
From a quick glance, Jan's abstraction isn't horrible. It has compress, but appears to be missing expand. Shouldn't be too hard to add later. And I find the choice against a VECTORLEN macro interesting. That may be necessary for SVE support. It breaks my mental model a bit, I currently assume that vectors are one of 16, 32 or 64 bytes. Jan's approach is probably better.
I dislike the idea of classes. Nothing about vector instructions implies an object-oriented approach. It doesn't prevent an object-oriented approach either, so classes clearly work. But for an abstraction it is an artificial limitation that is entirely unnecessary. I suppose it also indicates a cultural divide, you either prefer C or C++ and I happen to fall on the C side of that divide. Guess I will continue to use my way instead of the highway. ;)
>
> To expand on this a bit, I believe omp simd has a (near-)total lack of operations that cannot
> be expressed as C++ operators. By contrast, Highway provides about 100 such ops:
>
> https://github.com/google/highway/blob/master/g3doc/quick_reference.md#operations
There is a lot of value in abstractions. Instead of writing code in Assembler, we created languages like C. We now write code against the abstraction and let compilers map from the abstraction to appropriate assembly language. That concept worked well enough that we still a language designed for a PDP-11 even though most of us never saw a PDP-11 in our lifetime. The abstraction continues to work for CPUs designed decades after the abstraction.
Not all abstractions are equally good. You could argue that C aged better than Fortran or Cobol. Or if you dislike C, it is much harder to avoid than Fortran or Cobol.
There is also a lot of value in an abstraction for vector programming. Again, not all abstractions are equally good. And the problems are quite similar, you want something generic enough to cover all sorts of difference CPUs. And you want good enough performance when translated to actual CPUs that people don't resort to Assember or Intel intrinsics.
From a quick glance, Jan's abstraction isn't horrible. It has compress, but appears to be missing expand. Shouldn't be too hard to add later. And I find the choice against a VECTORLEN macro interesting. That may be necessary for SVE support. It breaks my mental model a bit, I currently assume that vectors are one of 16, 32 or 64 bytes. Jan's approach is probably better.
I dislike the idea of classes. Nothing about vector instructions implies an object-oriented approach. It doesn't prevent an object-oriented approach either, so classes clearly work. But for an abstraction it is an artificial limitation that is entirely unnecessary. I suppose it also indicates a cultural divide, you either prefer C or C++ and I happen to fall on the C side of that divide. Guess I will continue to use my way instead of the highway. ;)