Can nice D code get a bit slow?

[Guillaume Piolat]

On Wednesday, 8 March 2023 at 10:49:32 UTC, Markus wrote:
> Uh, hope you understand my vague question, sorry about that. I 
> found D to be the right place because it's not missing any 
> essential feature I know of.

Well, bounds check often cost a few percent, and you can disable 
it or use .ptr
@safe will push you to use slices instead of raw pointers, and 
those can occupy the stack a bit more, but it's not a huge effect.
Lack of dangerous "fast math" "optimizations" is a real boon for 
correctness.
We don't have integers overflows, those would also cost a few 
percent.

Your D programs by being easy to modify will have very few 
performance bottlenecks that are problematic, often the CPU-bound 
or memory-bound stuff that would be slow in any language. For 
example I like to merge array allocations, this necessitates the 
same code in C, C++, or any native language.

I think it's important not to go overboard with lazy chains and 
templates though.

Honestly the increased productivity will leave you ample time to 
make things fast, and you can use the native profilers, for 
example Intel Vtune.

This year I released a free VST compressor named Lens, it does 
more  than the closest manybands competitor while being in the 
ballpark CPU-wise, and they are using ICC AVX2 which does dynamic 
instruction set dispatch, while we use SSSE3. Optimization is all 
about having the time to do it.