Creator of LLVM, Clang, and Swift Says To Not Write Security Critical Code In C/C++

[via Digitalmars-d]

On Tuesday, 14 July 2015 at 21:18:03 UTC, H. S. Teoh wrote:
> Moral: Use a profiler. Don't believe in what you think is the 
> bottleneck, because you're almost always wrong. Don't believe 
> in your absolute confidence that the bottleneck must be that 
> ugly bit of code in object.d. Don't believe what your Finger of 
> Blame tells you is the bottleneck (in somebody else's code).

The only "somebody else's" code I call into in real time sections 
are FFT routines. I don't do system calls, I don't do 
allocations, I lock memory to RAM, I use my own lock free queues, 
I lay out data to avoid cache misses (at the expense of RAM). I 
do as little as possible in time critical sections... and as much 
as possible outside them, and yes those are "premature 
optimizations" that are difficult to work in later because then 
you essentially have to redesign the guts of the program...

> Only a profiler will tell you the true bottleneck. The true 
> bottleneck is almost always somewhere completely unexpected, 
> and nowhere near where you thought it would be.

Argh, no. The time spent is usually _exactly_ where I thought it 
would be. And the typical profiler won't help me all that much. 
For that I would need something more advanced (like v-tune etc).

> The sooner you learn to use a profiler, the less time you'll 
> waste optimizing things that don't matter while the real 
> bottlenecks continue to plague your performance.

Whhyyyyy are you guys assuming that people don't know how to use 
a profiler? It isn't exactly rocket science. I use them when I 
need them, and have since the early 90s, but I usually don't need 
them, and if I do I most likely need a specialized one that says 
something about hardware utilization. Regular profilers tell me 
very little. I know where my loops are! I don't do allocations, I 
don't do system calls, I have algorithms that can only be 
improved by putting more work into them at the expense of higher 
complexity... Which I don't want until I need it.

I am happy if I see that I have consistent 20% headroom, and I am 
not going to be happier by making my program faster...