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?