Modern C++ vs Managed Code: Performance vs Productivity
- Share
-
- |
Read later
My Reading List
An interesting discussion about the merits of native code versus Just-In-Time based systems has recently taken place with Herb Sutter of Microsoft and Miguel de Icaza of Mono both providing insightful commentary. Taken together they have provided an informative look at the current state-of-the-art in between native and managed code.
Herb Sutter began by answering the question, "When will better JITs save managed code?" Sutter summarizes his position with the statement that "C++ and managed languages make different fundamental tradeoffs that opt for either performance or productivity when they are in tension."
Sutter views C++ as settling the tradeoff by opting for performance whereas managed languages (which he defines as Java/NET) opt for programmer productivity. Providing more depth, Sutter goes on to say:
"First, JIT compilation isn’t the main issue. The root cause is much more fundamental: Managed languages made deliberate design tradeoffs to optimize for programmer productivity even when that was fundamentally in tension with, and at the expense of, performance efficiency."
Miguel de Icaza picked up on Sutter's points and provided his perspective shortly thereafter.
“Designers of managed languages have chosen the path of safety over performance for their designs. For example, accessing elements outside the boundaries of an array is an invalid operation that terminates program execution, as opposed to crashing or creating an exploitable security hole.”
The two differ on how each of them view the ability of a JIT based language to generate optimal code:
"Second, even if JIT were the only big issue, a JIT can never be as good as a regular optimizing compiler because a JIT compiler is in the business of being fast, not in the business of generating optimal code." – Herb Sutter
But I have an issue with [the above]. In general the statement is correct when it comes to early Just-in-Time compilers and perhaps reflects Microsoft's .NET JIT compiler, but this does not apply to state of the art JIT compilers. – Miguel de Icaza
de Icaza feels that JIT compilers must strike “...a balance between the quality of the generated code and the time it takes to generate the code. JIT compilers tend to go for fast compile times over [the] quality of the generated code.” However, Mono allows users to choose higher quality in their generated code by using LLVM to compile. de Icaza notes that “[Mono uses] the same compiler that Apple now uses on Lion and as LLVM improves, Mono's generated code improves.”
The ability to select the LLVM backend allows Mono users to choose between compilation speed and the quality of the generated code according to the needs of their particular project. This provides greater flexibility when developing as frequent recompilations are necessary during development and reducing compile time speeds development. Then when a project is at or near completion the selection for optimized code can be made to benefit end-users.
This is not to say that the choice of safety over performance does not mean managed runtimes cannot improve their performance further. de Icaza offers some areas for improvement, including intents, extending VMs, limiting dynamic language features, and better support for intrinsics that would map language features on to native hardware.
Sutter posted a follow up comment to his original post, and feels there is a fundamental performance advantage to C++:
“But there’s always an inescapable and fundamental difference between “prevention” and “cure” — when it comes to performance optimization, C++ always chooses “prevention,” and managed languages choose “cure” with the above-mentioned heroic efforts and many more. But the old ounce/pound saying is inescapable; you can’t beat prevention (in part because you can always add the cure after first doing the prevention, but not the reverse), and if you care about performance and control primarily then you should use a language that is designed to prioritize that up front, that’s all.”
How do InfoQ reader's feel about the tradeoffs between C++ and managed code? Do the developer advantages managed code promotes make up for any performance shortfalls? Does modern C++'s new features require a second look from managed code developers?
Prevention vs. Cure
by
Jerry Lam
State of art JIT produces more optimal code
by
peter lin
Re: Prevention vs. Cure
by
Serge Bureau
A JIT has dynamic informations not available to a compiler.
So in fact as JIT improves they should offer better performance than any compiler`s.
There is no amount of static analysis that can match the data from real runs.
So at first runs, compilers have an advantage but on programs running for a while JIT should be favored. And as evidence of this, many Java programs are faster than C++ equivalent.
They both missed that fact.
Re: State of art JIT produces more optimal code
by
Alex Hornby
Managed code is more than JIT alone
by
M Vleth
Welcome to 1995
by
Cameron Purdy
C++ is an abomination. Every time someone writes a line of C++ code, a kitten dies.
Either write in C, or use a proper high level language.
Peace,
Cameron Purdy
Both are missing the point.
by
Paulo Pinto
Herb focus only on C++ because it is what he cares about. Delphi, Ada, Modula-3, D are safe languages, with system programming capabilities, able to provide abstraction mechanisms similar to C++, while compiling to native code.
The best is to have an hybrid solution, similar to what environments like Lisp or Eiffel provide, by using a VM for quick turnaround development, with a full compile to native code for easy redistribution of binaries or environments where the usage of JIT is not possible.
Re: Welcome to 1995
by
Paulo Pinto
Most C++ compilers support for long time profile guided optimizations, which can help in the same way a JIT does. Grated you still cannot optimized to unknown architectures/instruction sets. But in .NET and JVM most special instruction sets (SSE, AVX,...) are also left unused.
Unfortunately C++ seems to be the only multi-paradigm high level language with native code generation implementations that is currently accepted in the industry.
Until a language with the same abstraction capabilities as C++, with native compiler implementation is accepted by the industry, C++ will continue to hold its position.
Re: Welcome to 1995
by
peter lin
You can put lipstick on a pig
by
Dan Tines
Re: You can put lipstick on a pig
by
peter lin
Test and Change
by
Glenn Graham
Space vs Time
by
Russell Leggett
Re: State of art JIT produces more optimal code
by
peter weissbrod
^^^ This.
I used to be a full-time C programmer, but these days I would only use C for very specialized, single purpose components where efficiency and speed are top priority. Once in a blue moon I will replace a slow function of managed code with a C module :)
Re: Space vs Time
by
peter lin
Re: Welcome to 1995
by
Charlie Helin
Re: Space vs Time
by
Charlie Helin
It is true that the JIT/Optimizer will figure out the 'intent' of the program rather than trying to follow it as is. I believe that most programmers are to smart for their own good and waste huge amount of time trying to be cute and obfuscate their code to impress colleagues, or just because it looks more intelligent write their program as it was an unmanaged environment. In short making their code less readable.
This unfortunately sometimes makes the job harder for the optimizer to figure out for instance if it is safe to hoist the "out of bounds check".
Educational Content
Large-Scale Continuous Testing in the Cloud
John Penix May 24, 2013
.jpg)
Managing Build Jobs for Continuous Delivery
Martin Peston May 24, 2013
Clojure in the Field
Stuart Halloway May 23, 2013
Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think