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

[NoUseForAName]

On Wednesday, 8 January 2014 at 19:17:08 UTC, H. S. Teoh wrote:
> On Wed, Jan 08, 2014 at 11:35:19AM +0000, Atila Neves wrote:
>> http://atilanevesoncode.wordpress.com/2014/01/08/adding-java-and-c-to-the-mqtt-benchmarks-or-how-i-learned-to-stop-worrying-and-love-the-garbage-collector/
>
> Manual memory management is a LOT of effort

Not in my experience. It only gets ugly if you attempt to write 
Ruby/Java in C/C++. In C/C++ you do not wildly create short-lived 
objects all over the place. In embedded C there is often no 
object allocation at all after initialization. I have written C 
and C++ code for 15 years and the only real issue was memory 
safety but you do not need a GC to solve that problem.

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

The performance issues of GC are not measured in percentages but 
in pause times. Those become problematic when - for example - 
your software must achieve a frame rate of at least 60 frames per 
second - every second. In future this will get worse because it 
seems the trend goes towards 120 Hz screens which require a frame 
rate of at least 120 frames per second for the best experience. 
Try squeezing D's stop-the-world GC pause times in there.

The D solution is to avoid the GC and fallback to C-style code. 
That is why Rust creates so much more excitement among C/C++ 
programmers. You get high-level code, memory safety AND no pause 
times.