Adding Java and C++ to the MQTT benchmarks or: How I Learned to Stop Worrying and Love the Garbage Collector

H. S. Teoh hsteoh at quickfur.ath.cx
Wed Jan 8 12:57:58 PST 2014


On Wed, Jan 08, 2014 at 09:23:48PM +0100, Benjamin Thaut wrote:
> Am 08.01.2014 20:15, schrieb H. S. Teoh:
> >Manual memory management is a LOT of effort, and to be quite honest,
> >unless you're writing an AAA 3D game engine, you don't *need* that
> >last 5% performance improvement that manual memory management *might*
> >gives you. That is, if you get it right. Which most C/C++ coders
> >don't.
> >
> 
> The problem is, that with the current D-GC its not 5%. Its 300%.
> See: http://3d.benjamin-thaut.de/?p=20

Well, your experience was based on writing a 3D game engine. :) I didn't
claim that GCs are best for that scenario. How many of us write 3D game
engines for a living?


> And people who are currently using C++ use C++ for a reason. And
> usually this reason is performance. As long as D remains with its
> current GC people will refuse to switch, given the 300% speed
> impact.

I think your view is skewed by your bad experience with doing 3D in D.
I've ported (well, more like re-written) compute-intensive code from
C/C++ to D before, and my experience has been that the D version is
either on par, or performs even better. Definitely nowhere near the 300%
slowdown you quote. (Not the mention the >50% reduction in development
time compared with writing it in C/C++!) Like I said, if you're doing
something that *needs* to squeeze every last bit of performance out of
the machine, then the GC may not be for you.

In fact, from what I hear, most people doing 3D engine work don't even
*use* memory allocation in the core engine -- everything is preallocated
so no allocation / free (not even malloc/free) is done at all. You never
know if a particular system's malloc/free relies on linear free lists,
which may cause O(n) worst-case performance -- something you definitely
want to avoid if you have only 20ms to render the next frame. If so,
then it's no wonder you see a 300% slowdown if you start using the GC
inside of the 3D engine.


> Additionaly programming with a GC often leads to a lot more
> allocations, and programmers beeing unaware of all those allocations
> and the possibility that those allocations slow down the program and
> might even trash the cache. Programmers who properly learned manual
> memory management are often more aware of whats happening in the
> background and how to optmize algorithms for memory usage, which can
> lead to astonishing performance improvements on modern hardware.

But the same programmers who don't know how to allocate properly on a
GC'd language will also write poorly-performing malloc/free code.
Freeing the root of a large tree structure can potentially run with no
fixed upper bound on time if the dtor recursively frees all child nodes,
so it's not that much better than a GC collection cycle. People who know
to avoid doing that will also know to write GC'd code in a way that
doesn't cause bad GC performance.


> Also a GC is for automatic memory management. But memory is just a
> resource. And there are a lot other resources then just memory.
> Having a GC does not free you from doing other manual memory
> management, which still can be annoying and can create the exact
> same issues as with manual memory management. Having a large C#
> codebase where almost everything implementes the IDisposeable
> interface doesn't really improve the situation. It would be a lot
> better if GCs would focus on automatic resource management in
> general, so the user is freed of all such tedious tasks, and not
> just a portion of it.

True, but having a GC for memory is still better than having nothing at
all. Memory, after all, is the most commonly used resource, generically
speaking.


> Additionaly switching away from C++ is also not a option because of
> other reasons. For example cross plattform compatibility. I don't
> know any language other then C/C++ which would actually work on all
> plattforms we (my team at work) currently develop for. Not even D
> (mostly because of missing ports of druntime / phobos. Maybe even a
> missing hardware architecture.)

That doesn't alleviate the painfulness of coding in C++.


> But I fully agree, that if you do some non performance critical
> business logic or application logic its a lot more productive to use a
> garbage collected language.

If you're doing performance-critical / realtime stuff, you probably want
to be very careful about how you use malloc/free anyway, same goes for
GC's.


> Unfortunately C# and Java are doing a far better job then D here,
> mostly because of better tooling and more mature libraries.
[...]

I find the lack of strong metaprogramming capabilities in Java (never
tried C# before) a show-stopper for me. You have to resort to either
lots of duplicated code, or adding too many indirections that hurts
performance.  For compute-intensive code, too many indirections can mean
the difference between something finishing in 2 days instead of 2 hours.


T

-- 
Computers are like a jungle: they have monitor lizards, rams, mice,
c-moss, binary trees... and bugs.


More information about the Digitalmars-d mailing list