3 ms·
“2) Use compiler built-ins and get portability across different HW at the expense of not supporting other compilers” Writing code to two specific compilers (cl
by Annatar 8y ago
“2) Use compiler built-ins and get portability across different HW at the expense of not supporting other compilers”
Writing code to two specific compilers (clang and gcc) is NOT portable code.
This is absolutely unacceptable behavior.
- AstralStorm 8y agoThe absolutely unacceptable thing is C still not having standard (optional) SIMD syntax. It at least finally got atomics. But wait, that's not portable to Keil so you cannot use that ;) The reaction is, if you dislike fast but non standard code, push for standardization of those features, not begrudge developers for doing the right thing and using them.
- exDM69 8y agoI agree that it's unacceptable that SIMD Vector extensions [0] are not standardized yet. However, they already work acceptably in GCC and Clang. There are only minor differences (e.g. __builtin_shufflevector) but it's usable with very minimal #ifdeffing. Example: typedef float vec4f __attribute__((vector_size(16))); // initializer vec4f a = { 1.0, 2.0, 3.0, 4.0 }; // literal expression vec4f b = a + (vec4f){ 5.0, 6.0, 7.0, 8.0 }; // standard infix operators vec4f c = -b * (a+b); // with --ffast-math, this will be a mad() It's not perfect but it's quite usable and I've been using vector extensions in C for years. [0] https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html
- Annatar 8y agoSIMD is processor specific, and is important only in certain scenarios. Trading portability for performance is a trade-off that most developers shouldn’t be willing to make if they are open sourcing their software, because it will prevent someone from running their software on that user’s desired platform, thereby showing the user the middle finger. That’s just wrong.