Linked by ebasconp on Fri 10th Jun 2011 22:22 UTC
Benchmarks "Google has released a research paper that suggests C++ is the best-performing programming language in the market. The internet giant implemented a compact algorithm in four languages - C++, Java, Scala and its own programming language Go - and then benchmarked results to find 'factors of difference'."
Thread beginning with comment 477074
To view parent comment, click here.
To read all comments associated with this story, please click here.
sakeniwefu
Member since:
2008-02-26


How do you suspect it performs in heavily threaded code? (you need mutexing both on the refcount and on your heap).

Faster than GC if it was to free memory at the same rate.

GC performs better than manual memory management only in a small subset of scenarios. It is true that it is good enough for many more, and that it keeps dumb programmers from freeing used objects and the like.

However, as soon as their design assumptions aren't met they fail badly. Generational GC aces object creation and destruction benchmarks. As true as it is that it bloats up until virtual memory dries up, when faced with real world apps that don't follow the general rule.

Reply Parent Score: 2

pantheraleo Member since:
2007-03-07

GC performs better than manual memory management only in a small subset of scenarios.


GC typically performs better in situations where there is a lot of fairly small amounts of memory allocation and deallocation happening in a relatively short period of time. The typical (and usually recommended) practice in C or C++, of course, is to free memory as soon as you are done with it. In this type of situation, that can create a lot of overhead. Garbage collection will use more memory of course, but will be significantly faster because it optimizes memory deallocation. The infilife algorithm is probably one of the simplest test cases where this pattern can be seen, and where GC runs circles around manual memory management.

It is true that it is good enough for many more, and that it keeps dumb programmers from freeing used objects and the like.


I don't think it's fair to use the word "dumb" really. Everyone makes mistakes, or sometimes forgets to free memory when they are done with it. And anyone who tells you they have never de-referenced a pointer that they though should point at something, but was actually null, is flat out lying. Especially in today's high pressure "release or die" environments where software release cycles tend to be very fast paced.

And of course, I'm sure I don't have to repeat it here because it is common knowledge these days. But with RAM and CPUs as cheap as they are these days, it's far more economical to throw another CPU, or throw more RAM at the problem, than it is to spend even a couple of hours trying to heavily optimize code to get just a little more speed or a little less memory consumption out of it.

And of course, that was one of the flaws with this benchmark, which Google admitted flat out. In the real world, no one spends that much time optimizing their C++ code. Not with development cycles as fast paced as they are today.

Edited 2011-06-13 13:43 UTC

Reply Parent Score: 2

zlynx Member since:
2005-07-20

And of course, I'm sure I don't have to repeat it here because it is common knowledge these days. But with RAM and CPUs as cheap as they are these days, it's far more economical to throw another CPU, or throw more RAM at the problem, than it is to spend even a couple of hours trying to heavily optimize code to get just a little more speed or a little less memory consumption out of it.


A little more speed? A little less memory consumption?

A popular Java program these days is Minecraft. I love it myself. But it has cases where, when memory consumption hits 700 MB or so, the game gets insanely choppy. This is the garbage collection happening. It sucks. It's unusable.

To fix it, the recommendation is to run the 64-bit server JVM and let it use a gigabyte of RAM.

A whole gigabyte, to hold a chunk of active blocks which, if stored in a well-thought out C++ data structure, would only take a hundred megabytes or so.

Reply Parent Score: 2

TemporalBeing Member since:
2007-08-22

"GC performs better than manual memory management only in a small subset of scenarios.


GC typically performs better in situations where there is a lot of fairly small amounts of memory allocation and deallocation happening in a relatively short period of time. The typical (and usually recommended) practice in C or C++, of course, is to free memory as soon as you are done with it. In this type of situation, that can create a lot of overhead. Garbage collection will use more memory of course, but will be significantly faster because it optimizes memory deallocation. The infilife algorithm is probably one of the simplest test cases where this pattern can be seen, and where GC runs circles around manual memory management.
"

Problem with GC is that your applications take a performance penalty at unpredictable times - whenever the GC decides to clean-up. That can adversely affect the rest of the application and you have little to no control over it. Yes, some GC algorithms allow you to specify a good time to do GC clean-up, but AFAIK they are neither popular nor the 'top dog' algorithms.

Reply Parent Score: 2

f0dder Member since:
2009-08-05

"
How do you suspect it performs in heavily threaded code? (you need mutexing both on the refcount and on your heap).

Faster than GC if it was to free memory at the same rate.
"...and the whole point is that you aren't doing it that way when you're dealing with GC, leading to scenarios where you get much better performance. Right tool for the job and all that, ever heard about it? ;)

Of course you can spend a lot of time developing a different approach in C++, or you can spend time writing a custom memory allocator with different characteristics, but that's not always time effective.

It is true that it is good enough for many more, and that it keeps dumb programmers from freeing used objects and the like.
You generally have to be more careful wrt. deallocation in GC languages since they typically only deal with memory rather than resources, whereas in C++ we can utilize the wonderful RAII. If you think Java and C# programmers are "dumb" and/or lazy because of GC, I suspect you haven't done much development in either of those languages.

Reply Parent Score: 1