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

[H. S. Teoh]

On Thu, Jan 09, 2014 at 07:01:59PM +0000, Sean Kelly wrote:
> On Wednesday, 8 January 2014 at 19:17:08 UTC, H. S. Teoh wrote:
[...]
> >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 other common case is server apps, since unpredictable delays
> can be quite undesirable as well.  Java seems to mostly get
> around this by having very mature and capable GCs despite having
> a standard library that wants you to churn through memory like
> pies at an eating contest.  The best you can do with D so far is
> mostly to just not allocate whenever possible, by slicing strings
> and such, since scanning can still be costly.  I think there's
> still some work to do here, despite loving the GC as a general
> feature.

I think we all agree that D's GC in its current state needs a lot of
improvement. While I have come to accept GCs as a good thing, that
doesn't mean that D's current GC is *that* good. Yet. I wish I had the
know-how (and the time!) to improve D's GC, because if D can get a GC
that's on par with Java's, then D can totally beat Java flat, since the
existence of value types greatly reduces the memory pressure on the GC,
so the GC will have much less work to do compared to an equivalent Java
program.

OTOH, even with D's suboptimal GC, I'm already seeing great productivity
gains at only a low cost, so that's a big thumbs up for GC's. And the
nice thing about being able to call malloc from D (which you can't in
Java) means you can still do manual memory management in critical code
sections when you need to squeeze out some extra performance.


T

-- 
Turning your clock 15 minutes ahead won't cure lateness---you're just making time go faster!