Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>A lot of it comes down to a simple difference between fact and theory. People have advanced <a href="http://www.idiom.com/~zilla/Computer/javaCbenchmark.html" rel="nofollow noreferrer">theories</a> to explain why Java should be (or at least might be) faster than C++. Most of the arguments have little to do with Java or C++ <em>per se</em>, but to dynamic versus static compilation, with Java and C++ really being little more than examples of the two (though, of course, it's possible to compile Java statically, or C++ dynamically). Most of these people have benchmarks to "prove" their claim. When those benchmarks are <a href="http://www.freewebs.com/godaves/javabench_revisited/" rel="nofollow noreferrer">examined</a> in any detail, it quickly becomes obvious that in quite a few cases, they took rather extreme measures to get the results they wanted (e.g., quite a number <em>enable</em> optimization when compiling the Java, but specifically <em>disabled</em> optimization when compiling the C++).</p> <p>Compare this to the <a href="http://benchmarksgame.alioth.debian.org/u64q/which-programs-are-fastest.html" rel="nofollow noreferrer">Computer Language Benchmarks Game</a>, where pretty much anybody can submit an entry, so all of the code tends to be optimized to a reasonable degree (and, in a few cases, even an unreasonable degree). It seems pretty clear that a fair number of people treat this as essentially a competition, with advocates of each language doing their best to "prove" that their preferred language is best. Since anybody can submit an implementation of any problem, a particularly poor submission has little effect on overall results. In this situation, C and C++ emerge as clear leaders.</p> <p>Worse, if anything these results probably show Java in <em>better</em> light than is entirely accurate. In particular, somebody who uses C or C++ and really cares about performance can (and often will) use Intel's compiler instead of g++. This will <em>typically</em> give at least a 20% improvement in speed compared to g++.</p> <p>Edit (in response to a couple of points raised by jalf, but really too long to fit reasonably in comments):</p> <ol> <li><p>pointers being an optimizer writers nightmare. This is really overstating things (quite) a bit. Pointers lead to the possibility of aliasing, which prevents certain optimizations under certain circumstances. That said, inlining prevents the ill effects much of the time (i.e., the compiler can detect whether there's aliasing rather than always generating code under the assumption that there could be). Even when the code does have to assume aliasing, caching minimizes the performance hit from doing so (i.e., data in L1 cache is only <em>minutely</em> slower than data in a register). Preventing aliasing would help performance in C++, but not nearly as much as you might think.</p></li> <li><p>Allocation being a lot faster with a garbage collector. It's certainly true that the <em>default</em> allocator in many C++ implementations is slower than what most (current) garbage collected allocators provide. This is balanced (to at least a degree) by the fact that allocations in C++ tend to be on the stack, which is also fast, whereas in a GC language nearly all allocations are usually on the heap. Worse, in a managed language you usually allocate space for each object individually whereas in C++ you're normally allocating space for all the objects in a scope together.</p></li> </ol> <p>It's also true that C++ directly supports replacing allocators both globally and on a class-by-class basis, so when/if allocation speed really is a problem it's usually fairly easy to fix.</p> <p>Ultimately, jalf is right: both of these points undoubtedly <em>do</em> favor "managed" implementations. The degree of that improvement should be kept in perspective though: they're not enough to let dynamically compiled implementations run faster on much code -- not even benchmarks designed from the beginning to favor them as much as possible.</p> <p>Edit2: I see Jon Harrop has attempted to insert his two (billionths of a) cent's worth. For those who don't know him, Jon's been a <a href="http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/9f3219d715a24d01/7f66e71bdbcf0ffc?hl=en&amp;ie=UTF-8&amp;q=jon+harrop+troll#7f66e71bdbcf0ffc" rel="nofollow noreferrer">notorious</a> <a href="http://tfeb.org/lisp/mad-people.html" rel="nofollow noreferrer">troll</a> <a href="http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/403816728086368f/3d93fc28f270e275?hl=en#3d93fc28f270e275" rel="nofollow noreferrer">and</a> <a href="http://groups.google.com/group/microsoft.public.dotnet.languages.csharp/browse_thread/thread/cce63509c668bd89/ced23b49bc2412c9?hl=en&amp;ie=UTF-8&amp;q=jon+harrop+troll#ced23b49bc2412c9" rel="nofollow noreferrer">spammer</a> <a href="http://www.velocityreviews.com/forums/t597280-who-uses-java.html" rel="nofollow noreferrer">for</a> <a href="http://groups.google.com/group/comp.sys.mac.advocacy/browse_thread/thread/a10d3b9daa38ee52/3bb0506e79415c?hl=en&amp;ie=UTF-8&amp;q=jon+harrop+troll#003bb0506e79415c" rel="nofollow noreferrer">years</a>, and seems to be looking for new ground into which to sow weeds. I'd try to reply to his comment in detail, but (as is typical for him) it consists solely of unqualified, unsupported generalizations containing so little actual content that a meaningful reply is impossible. About all that can be done is to give onlookers fair warning that he's become well known for being dishonest, self-serving, and best ignored.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload