|
|
|
|
|
|
by geokon
3029 days ago
|
|
|
right, so things that are not part of the language, not crossplatform and not crosscompiler. That's called fighting the language in my book :) I'm not saying you can't get C++ to output the assembly you want - it just sucks trying to coerce it to do things that are honestly not that complicated. And even when you do get what you want you find you can't use the code anywhere else. To me that feels like a language failure... > is the fact that almost no other languages offer any of these I guess you missed my point. It seems to me that we're at a point where you no longer need these features as part of your core application language. The idea is that with OpenCL/SPIR-V we'll be able to 1- be more explicit and not fight the language (so even if you're 100% on the CPU it makes sense) 2- target every platform (you can finally write code for your GPU) 3- can be called from any parent language You're right that not all performance critical problems boil down to tight shared-memory loops that can be thrown onto an OpenCL kernel - but my experience so far tells me that that's the vast majority of performance problems. So C++'s usefulness will shrink. But maybe my experience is biased and I'm off base. I haven't done much OpenCL myself - but I'm definitely planning to use it more in the future |
|
|
You just have a header with different #defines for the different platforms you are going to ship on, or use a premade open source one.
If you want to ship on everything, you won't get full optimization stuff everywhere. It would be better if some of these features were in the standard, but in practice it isn't such a big issue for those two in particular.