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

[Benjamin Thaut]

Am 08.01.2014 21:57, schrieb H. S. Teoh:
> On Wed, Jan 08, 2014 at 09:23:48PM +0100, Benjamin Thaut wrote:
>
> 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?

No, this expierence is not only based of this. I observed multiple 
discussions on the newsgroup, where turning off the GC would speed up 
the program by factor 3. The most recent one was parsing a text file and 
filling a associative array with the contents of that text file, which 
is not really 3d programming. What I'm really trying to say is: I would 
be willing to use a GC in D to, but only if D actually has a state of 
the art GC and not some primitive old does work without language support GC.

>
> 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.

That is a common misconception you can read very often on the internet. 
That doesn't make it true however. I saw lots of game and engine code in 
my life already, and its far from preallocating everything. It is tried 
to keep allocations to a minimum, but they are not avoided at all costs. 
If its neccessary they are just done (for example when spawning a new 
object, like a particle effect). It is even common to use scripting 
languages like lua for some tasks in game development, and lua allocates 
quite a lot during execution.

>
> 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.

That is another common argument of pro GC people I have never seen in 
partice yet. Meaning, I never seen a case where freeing a tree of 
objects would cause a significant enough slowdown. I however saw lots of 
cases where a garbage collection caused a significant slowdown.

>
>
> 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.
>

Still it only solves half the problem.

>
>> 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++.

It was never intended to. I just wanted to make the point, that even if 
you want, you can't avoid 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.

This statement again has been posted hunderts of times in the GC vs 
manual memory management discussion. And again I never saw that the 
execution time of malloc or other self written allocators are a problem 
in partice. I did however see that the runtime of a GC allocation became 
a problem, to the point where it is avoided entierly. With realtime I 
didn't really mean that "hard" realtime requirements of embeded systems 
and alike more like "soft" realtime requirements where you want to avoid 
pause times as much as possible.

>
>
> 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.
>

I fully agree here. Still when choosing a programming language you also 
have to pick one that all programmers on the team can and want to use. I 
fear that the D metaprogramming capabilities will scare of quite a few 
programmers because it seems to complicated to them. (Its really the 
same with C++ metaprogramming. Its syntactically ugly and verbose, but 
gets the job done, and is not so complicated if you are familiar with 
the most important concepts).