Timeline for What backs up the claim that C++ can be faster than a JVM or CLR with JIT?
Current License: CC BY-SA 3.0
22 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 6, 2012 at 15:29 | history | undeleted | superM | ||
| Aug 6, 2012 at 15:21 | history | deleted | superM | ||
| Aug 6, 2012 at 7:49 | comment | added | superM | @Orion Edwards, yes. That's what I say, and also I described why this is so in a few words. For more info, please the the book I've added to my answer. | |
| Aug 6, 2012 at 6:31 | history | edited | superM | CC BY-SA 3.0 |
added 154 characters in body
|
| Aug 5, 2012 at 21:31 | comment | added | Orion Edwards | @superM which CLR are you talking about? While the .NET JIT compiler is often pretty good, there's lots of optimizations it simply doesn't seem to do. That, plus the fact that every object in .NET no matter how small consumes at least 12 bytes, means I've yet to see a .NET program run faster than a C++ one | |
| Aug 4, 2012 at 19:39 | comment | added | josefx | @ErikReppen the statement "an abstraction that translates to multiple platforms" also fits c++, so by your own statement c++ is as slow as java. In reality java is just more restrictive about the behavior of its abstract machine, which makes it impossible to write those nice non portable speedups in java. | |
| Aug 4, 2012 at 12:54 | comment | added | tdammers | @Carson63000: Yes, of course this is possible - when you distribute binaries, you can't optimize for one particular target; this is what JIT compilers are good at - adapting themselves to a particular platform. I'm pretty sure however that if you could make builds for individual machines, a precompiled binary would be just as fast as a JIT-compiled one, and it would have the additional advantage of not having to run the JIT compiler. With source distributions, this approach is actually being used; a typical configure script probes the system and adjusts compiler settings accordingly. | |
| Aug 3, 2012 at 23:58 | comment | added | Carson63000 | @tdammers: did you ever hear of HP's Project Dynamo? They demonstrated that they could improve the performance of a native, statically optimized program binary, by using JIT techniques to modify the code during execution, effecting compiling machine language to more optimized machine language. | |
| Aug 3, 2012 at 22:55 | comment | added | gbjbaanb | @Zaviour: JIT provides benefits other than performance. The inventors assumed that everyone would have faster and faster CPUs that made the perf issues with JIT insignificant. They were partly right - my quad 3ghz CPU is good enough, but that doesn't mean it's as fast as a native binary, as phone and cloud devs are finding out. They also assumes memory would become cheaper and cheaper, but again - it isn't used as efficiently as native binaries use it. Its a big trade-off between dev productivity and hardware efficiency which sometimes is a trade-off worth having. | |
| Aug 3, 2012 at 22:13 | comment | added | Erik Reppen | Why are you linking to Sun for performance claims about their own products? And why are guys even trying to argue Java might be up to C++ standards for performance? It is simply not possible to have that fine-grained level of control over performance when you're writing to an abstraction that translates to multiple platforms. | |
| Aug 3, 2012 at 16:54 | comment | added | Charles E. Grant | @Tdammmers, actually there is a performance component too. See java.sun.com/products/hotspot/whitepaper.html. Optimizations can include things like dynamic adjustments to improve branch prediction and cache hits, dynamic inlining, de-virtualization, disabling of bounds checking, and loop unrolling. The claim is that in many cases these can more than pay for the cost of JIT. | |
| Aug 3, 2012 at 15:06 | comment | added | tdammers | JIT (or rather, the bytecode approach) isn't used for performance, but for convenience. Instead of pre-building binaries for each platform (or a common subset, which is sub-optimal for every one of them), you compile only halfway and let the JIT compiler do the rest. 'Write once, deploy anywhere' is why it's done this way. The convenience can be had with just a bytecode interpreter, but JIT does make it faster than the raw interpreter (though not necessarily fast enough to beat a pre-compiled solution; JIT compilation does take time, and the result doesn't always make up for it). | |
| Aug 3, 2012 at 15:03 | comment | added | tdammers | @Darthfett: it has a positive effect compared to interpreting, but if you already have a precompiled binary optimized to the current platform, there isn't much a JIT compiler can do to beat it, except adjusting its optimization parameters based on actual usage and recompiling on the fly. | |
| Aug 3, 2012 at 14:56 | comment | added | Casey Kuball | JIT has a positive effect on performance, not a negative, if you put it into context -- It's compiling byte code into machine code before running it. The results can also be cached, allowing it to run faster than equivalent byte-code that is interpreted. | |
| Aug 3, 2012 at 14:46 | history | edited | superM | CC BY-SA 3.0 |
deleted 4 characters in body
|
| Aug 3, 2012 at 14:45 | comment | added | Zavior | @Anon I agree that it has extra overhead, but I guess the gains make up for it. Dont have any any sources to back it up, would make sense though! | |
| Aug 3, 2012 at 14:44 | comment | added | superM | @Anonymous, I can't say for sure, but Java has many abstraction layers. By this I mean that the string, for example, doesn't turn immediately to call native-api. C++ and C# don't have this folly. | |
| Aug 3, 2012 at 14:43 | comment | added | Anonymous | @Zavior - I can't think of a good answer to your question, but I don't see how JIT can't add extra performance overhead - the JIT is an extra process to be completed at run time that requires resources that aren't being spent on execution of the program itself, whereas a fully compiled language is 'ready to go'. | |
| Aug 3, 2012 at 14:41 | comment | added | superM | @Zavior, JIT has MANY advantages. People at Microsoft and Sun/Oracle aren't that stupid to create something new if it has no valuable advantages. | |
| Aug 3, 2012 at 14:40 | comment | added | Anonymous | This part of the concept I understand. My question could probably have been better worded to something like "is the only performance difference between compiled and intermediate languages the fact that there is no JIT compiler overhead in compiled languages, if not, what are the other contributors?". Though the simple answer to that question i'm assuming is 'No' - and that's what I'm interested in finding out - what other factors contribute to performance deviations. | |
| Aug 3, 2012 at 14:39 | comment | added | Zavior | If JIT actually had a negative impact on performance, surely it would not be used? | |
| Aug 3, 2012 at 14:36 | history | answered | superM | CC BY-SA 3.0 |