Creator of LLVM, Clang, and Swift Says To Not Write Security Critical Code In C/C++
via Digitalmars-d
digitalmars-d at puremagic.com
Tue Jul 14 17:28:46 PDT 2015
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...
More information about the Digitalmars-d
mailing list