Comment by flohofwoe | Hacker News Reader

Comment by flohofwoe | Hacker News Reader

Parent Full thread

> (on SIMD) C never really added any kind of abstraction for them.

ISPC and various C-derived GPU shading languages would beg to differ. But then the next question is: are high-level abstractions and 'compiler magic' even all that useful for SIMD, or are intrinsics the better solution?

None of those things are part of the C standard of course, but in the real world the C standard does not matter - only the feature set of actually existing compilers does.

Also I wish that obsession with the PDP-11 would finally die. C seems to be a pretty good match for all sorts of von-Neumann-computers, otherwise it would have died already.

IMHO programming languages live and die with the hardware they need to - uh - 'program', a hardware architecture which requires an entirely new approach to programming will naturally require entirely different programming languages (and our computers still are close enough to computers from the 50's and 60's that the same programming languages map pretty well).

It makes a lot more sense to speculate what hardware will look like in 100 years, because only this will tell what programming languages might look like.

I agree for instance gcc's vector size attribute works just fine in C. For instance I could declare a type like this:

typedef uint32_t myVec __attribute__((vector_size(16)));

and then when using that type in C, gcc alot times will do a great job vectorizing without having to reach towards intrinsics when looking at the generated code.

Sure it's not standard C, but it still feel like C when using them. Even for things like shuffling it's still pretty logical to just treat it as a function for instance "__builtin_shuffle" that gcc provides to use on those vector types.

The semantics of C can handle such things, it's just not standardized if you get what I am saying. So I get what your saying about the PDP-11.

Just because certain shading languages put on a C-like syntax doesn’t make them anywhere close to C. They have entirely different semantics. So no, C is just terrible when it comes to SIMD, but also when it comes to multi-threading, two areas that are the most important inprovements of modern hardware.

Some are less different than others, for instance:

"The Metal programming language is a C++14-based Specification with extensions and restrictions. Refer to the C++14 Specification (also known as the ISO/IEC JTC1/SC22/WG21 N4431 Language Specification) for a detailed description of the language grammar."

(from: https://developer.apple.com/metal/Metal-Shading-Language-Spe...)

Meaning essentially that MSL is C++14 with a couple of restrictions (mostly concerning pointers), a couple of SIMD data types, and some custom attributes.

...the C++14 could just as well be replaced with some C standard, if the Metal designers wouldn't like C++ so much for mysterious reasons (and that arguably would have been the better choice - because for shader programming C++ really doesn't add that much useful stuff over C).

C++ is very different from C, one language is actually usably expressive the other can’t even express a generic vector data structure without runtime overhead or copy-pasting.

Not going to argue, but if you really want generics in C the usual solution is code generation. Also, it might be surprising to a C++ coder, but there's a lot of problems that can be solved perfectly fine without generics ;)

Reply on news.ycombinator.com