On Sunday, 29 December 2013 at 15:22:29 UTC, Andrei Alexandrescu
wrote:
Wait, what? Go excused itself out of the competition, and you'd
Agree. I consider Go to be a web-service language atm.
need to bring some evidence that D is not as fast/tight as C++.
I have accumulated quite a bit of evidence the other way
without even trying.
One example: Performant C++ is actually C with a bit of C++
convinience, so you toss out exception handling, stack unwinding
and even turn off stack frames. With that and allocation pools
you can backtrack by simply setting the stack-pointer and
dropping the pool. C is so barebones that you can do your own
coroutines without language support if you wish.
As long as you only call nothrow functions you can do this? So
you can use slower C++ convinience for initialization and
close-to-the-metal after that.
the standard library. But claiming that D code can't be
efficient because of some stdlib artifacts is like claiming C++
code can't do efficient I/O because it must use iostreams
(which are indeed objectively and undeniably horrifically
slow). Neither argument has merit.
Well, but people who care about real-time performance in C++ use
libraries that stays clear of those areas. C++ stdlib is more for
medium-performance code sections than high-performance code.
The GC trash cashes when it kicks in. That affect real-time
threads where you basically have hard real-time requirements.
That means you need higher headroom (can do less
signal-processsing in an audio realtime thread).
