C++ – care about micro performance and efficency

The comments by @ratchet, @Sjoerd and @Stephane answer you question.

Your assertion in the question "All I currently know is that doubles are probably the most expensive because they are larger" shows the rules about optimization - are true - "Only for experts" followed by the "Your not an expert yet" .....

Unless you know the minutest details of the underlying hardware AND how the compiler utilizes those, you cannot make any assertions about floating point numbers. You can't even be certain that a floating point operation takes more time than an integer operation. As a rule, there is enough problems with programmers writing floating point code correctly, that it should be avoided unless needed. If needed, performance is of little concern.

As a rule of thumb - use ints if possible - it's rarely slower then FP operations, and often faster, and more predictable. If you must use FP operations, use doubles. Floats do not have a large enough mantissa for anything but the roughest of calculations (unless extreme care is taken) and a prone to insidious rounding errors.

However, like all rules of thumb, they need to be applied appropriately. If it matters - measure it.

I did not write much SIMD code for myself, but a lot of assembler code some decades ago. AFAIK using SIMD intrinsics is essentially assembler programming, and your whole question could be rephrased just by replacing "SIMD" by the word "assembly". For example, the points you already mentioned, like

• the code takes 10x to 100x to develop than "high level code"

• it is tied to a specific architecture

• the code is never "clean" nor easy to refactor

• you need experts for writing and maintaining it

• debugging and maintaining is hard, evolving really hard

are in no way "special" to SIMD - these points are true for any kind of assembly language, and they are all "industry consensus". And the conclusion in the software industry is also pretty much the same as for assembler:

• don't write it if you don't have to - use a high level language whereever possible and let compilers do the hard work

• if the compilers are not sufficient, at least encapsulate the "low level" parts in some libraries, but avoid to spread the code all over your program

• since it is almost impossible to write "self-documenting" assembler or SIMD code, try to balance this by lots of documentation.

Of course, there is indeed a difference to the situation with "classic" assembly or machine code: today, modern compilers typically produce high quality machine code from a high level language, which is often better optimized than assembler code written manually. For the SIMD architectures which are popular today, the quality of the available compilers is AFAIK far below that - and maybe it will never reach that, since automatic vectorization is still a topic of scientific research. See, for example, this article which describes the differences in opimization between a compiler and a human, giving a notion that it might be very hard to create good SIMD compilers.

As you described in your question already, there exist also a quality problem with current state-of-the-art libraries. So IMHO best we can hope is that in the next years the quality of the compilers and libraries will increase, maybe the SIMD hardware will have to change to become more "compiler friendly", maybe specialized programming languages supporting easier vectorization (like Halide, which you mentioned twice) will become more popular (wasn't that already a strength of Fortran?). According to Wikipedia, SIMD became "a mass product" around 15 to 20 years ago (and Halide is less than 3 years old, when I interpret the docs correctly). Compare this to the time compilers for "classic" assembly language needed to become mature. According to this Wikipedia article it took almost 30 years (from ~1970 to the end of the 1990s) until compilers exceeded the performance of human experts (in producing non-parallel machine code). So we may just have to wait more 10 to 15 years until the same happens to SIMD-enabled compilers.