JIT compiled code vs native machine code
Author
Hey all,
I have been trying to figure out which methodology is optimum, using a language like C++, which compiles to native machine code, or a language like C#, which is JIT compiled.
You might think it's obvious that pre-compiled programs run faster, but upon closer investigation, JIT compiling, in theory (also in practice?) would be the optimal way to go. The reason I say this is because JIT compiling gives you the advantage that the machine code it generates is optimized to the specific processor the code runs on, while code that is compiled straight to machine code has no way of knowing the exact processor it will run on (apart from general knowledge like it is on an x86 architecture).
I'm really curious about this because, as many of you who program out there might agree with, C++ is a p.i.t.a. to work with sometimes, and languages like C# have some nice features, and are a lot easier to work with.
Have there been many studies done on this? What do you guys think? Any experiences that have you lean one way or the other?
JIT compilation is potentially far better. It has access to more of the program, processor specific features [like you said] and can perform analysis that just plain can't be performed in a statically compiled but dynamically linked sort of environment.
That said, performing this sort of analysis is computationally expensive. The result is that corners are cut in favor of getting the program up and running as fast as possible, where as computation time is largely irrelevant to a statically compiled program [not really, but a day-long compile is tolerable in this environment, where as JIT compilers are expected to work in a fraction of a second]. There is simply more that can be done in a JIT compiled environment, but this added effort is very rarely taken because of the real-world time it takes to do it. Hopefully, multi-core machines will begin to influence this, as JIT compiled code also can be compiled incrementally, but such a thing is pretty rare to see used in practice currently [at least not to the degree that it could be used]. Without a shadow of a doubt though, more can be done in a JIT compiler than in a static compiler.
That said, performing this sort of analysis is computationally expensive. The result is that corners are cut in favor of getting the program up and running as fast as possible, where as computation time is largely irrelevant to a statically compiled program [not really, but a day-long compile is tolerable in this environment, where as JIT compilers are expected to work in a fraction of a second]. There is simply more that can be done in a JIT compiled environment, but this added effort is very rarely taken because of the real-world time it takes to do it. Hopefully, multi-core machines will begin to influence this, as JIT compiled code also can be compiled incrementally, but such a thing is pretty rare to see used in practice currently [at least not to the degree that it could be used]. Without a shadow of a doubt though, more can be done in a JIT compiler than in a static compiler.
While its important to wring the most that you can from your code, the binary/ISA level is really the last thing you should be worrying about. Ask yourself honestly if you're going to be in the position to spend 50% of your time getting another 10-15% performance. Are you going to be making a game that's comparable to Rage or Crysis any time soon? Unless you're on that level, you can accomplish really any game with more straight-forward techniques.
Things like good algorithms, data structures and memory usage are far more important for performance, and really none of those things can be done better in any one language over another, if they provide comparable facilities.
In theory, yes JIT code is able to compile for the actual hardware that its running on, however I don't believe that that is exploited to the fullest at this point. Code optimization isn't a simple thing, and even high-end, expensive, stand-alone compilers aren't able to do much with things like auto-vectorization. Native code, for now, generally wins.
Things like good algorithms, data structures and memory usage are far more important for performance, and really none of those things can be done better in any one language over another, if they provide comparable facilities.
In theory, yes JIT code is able to compile for the actual hardware that its running on, however I don't believe that that is exploited to the fullest at this point. Code optimization isn't a simple thing, and even high-end, expensive, stand-alone compilers aren't able to do much with things like auto-vectorization. Native code, for now, generally wins.
In theory, JIT compiling is superior. In practice, it's more or less a wash.
Regardless, unless you are talking about doing distributed computing across huge numbers of nodes, or something similar, the speed difference is completely and utterly irrelevant.
Programmer productivity is infinitely more important than a few milliseconds.
Regardless, unless you are talking about doing distributed computing across huge numbers of nodes, or something similar, the speed difference is completely and utterly irrelevant.
Programmer productivity is infinitely more important than a few milliseconds.
Quote:Original post by zenprogrammer
You might think it's obvious that pre-compiled programs run faster, but upon closer investigation, JIT compiling, in theory (also in practice?) would be the optimal way to go.
In theory: Yes.
In reality: [lol] [lol] [lol] [lol]
Static compilation technology has had a good four decades or so to evolve, much of it focused on compilation of C and later C++. A modern C++ compiler is beastly when it comes to generating lean, fast machine code. Even the bad ones, like GCC. Modern techniques like whole program analysis and link time code generation, while expensive, provide fantastic results.
JIT, while theoretically way better, performs quite poorly in reality. Nevermind runtime JIT, even ahead of time JIT ("Ngen" in the .NET world) doesn't perform at nearly the same level. I'm not entirely clear on why this is the case, although I'm sure there are good reasons. But the current crop of JIT engines are poor at basic tasks like inlining, let alone tasks like autovectorization that are difficult even in static compilation. (Why Microsoft is 3.5 versions in and hasn't bothered to provide something like Mono.Simd yet is beyond me.)
It wasn't that long ago we were still coding assembly to really get the last mile. Quake 2's software renderer comes to mind -- that was only a bit over 11 years ago.
Sooo...wait until 2020 and we're golden?
Of course, while JIT itself is fairly awful, JIT based runtimes have a number of very interesting properties, primarily centered around memory usage, that make them absolutely fabulous for performance in some scenarios. They can match or outrun a competently designed and comparable C++ program, with a fraction of the development time. While the C++ code could theoretically match this, it'd basically involve a wholesale reimplementation of the runtime engine powering the managed language. So don't center your attention around just the JIT when it comes to performance.
P.S. C++ vs C# is still not allowed and I will still be deleting posts on a whim.
I'm by no means an expert on the subject, but in this talk one of the developers of XNA likens machine code created by the JIT with a 90ies C++ compiler. That is, the machine code generated by the JIT is poorly optimized, just as machine code from C++ compilers were in the 90ies, but it still _is_ machine code. So if you know what you are doing you can, theoretically, get a very good performance out of C#, you just have to do the optimizing yourself.
Author
Quote:Original post by Promit
P.S. C++ vs C# is still not allowed and I will still be deleting posts on a whim.
Oh snap! I wasn't aware it came across like that. Really the question isn't aimed at a particular language, I'm mostly concerned about compilation methods.
I think some of the new features introduced in Visual Studio can really affect this comparison. The addition of profile guided optimization really brings the best of both worlds. You get the native speed of static code with the additional performance gains you'd get from run-time optimizations.
Although, generated profile data is a total pain and the whole process is rather cumbersome, the outcome is sometimes really significant.
I find worrying about this sort of thing, although an interesting discussion, just gets in the way of writing applications (and getting actual work done.)
Although, generated profile data is a total pain and the whole process is rather cumbersome, the outcome is sometimes really significant.
I find worrying about this sort of thing, although an interesting discussion, just gets in the way of writing applications (and getting actual work done.)
Author
Quote:Original post by AAA
I find worrying about this sort of thing, although an interesting discussion, just gets in the way of writing applications (and getting actual work done.)
Before one writes an application, there are many important things to consider in the apps architecture. Surely, if we are to be GOOD Software Engineers, our systems must be well planned BEFORE any code is written. Saavy?
Quote:
Before one writes an application, there are many important things to consider in the apps architecture. Surely, if we are to be GOOD Software Engineers, our systems must be well planned BEFORE any code is written. Saavy?
There are more important factors to consider -- those that can actually have an impact on design and architecture -- than whether the program will be at it's heart native-compiled or JIT'd.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
