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 477076
To view parent comment, click here.
To read all comments associated with this story, please click here.
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

pantheraleo Member since:
2007-03-07

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.


That sounds like bad programming to me. Probably excessive object creation, which could likely be found and fixed with a profiler actually.

I've done a fair amount of Java3D programming myself, and don't have this problem with things I have written.

Also, this problem is not unique to Java. I've seen C++ games that have similar problems for the same reason. Excessive object creation. Without careful planning, that's an easy trap to fall into in any object oriented language when doing game development with it.

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.


See what I said above. The exact same thing is true in Java. A well-thought out data structure in Java could avoid this problem. Don't blame Java for bad programming technique on the part of the developer. You could get yourself into the exact same trouble with C++ if you naively used a separate object to hold each block, and then ended up with excessive object creation because of it. This is bad programming technique. Not the fault of Java.

Edited 2011-06-13 18:04 UTC

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

pantheraleo Member since:
2007-03-07

Problem with GC is that your applications take a performance penalty at unpredictable times - whenever the GC decides to clean-up.


Java's default GC behavior (you can tweak it with command line switches) is to try to run GC as an idle task. it will try to wait until no other higher priority threads in the VM are scheduled to run before it does GC. Of course, this isn't always possible if the application is very busy. In those cases, if memory starts to reach the maximum allowed heap space that is configured for the JVM, then the GC might have to run at a less opportune time.

But ideally, it will try to do it as an idle task. Unless it is forced to do otherwise because it is getting close to hitting max heap size.

Reply Parent Score: 2