title: What are the advantages of just-in-time compilation versus ahead-of-time compilation?
body: <p>I've been thinking about it lately, and it seems to me that most advantages given to <strong>JIT</strong> compilation should more or less be attributed to the intermediate format instead, and that jitting in itself is not much of a good way to generate code.</p>
  
  <p>So these are the main <strong>pro-JIT</strong> compilation arguments I usually hear:</p>
  
  <ol>
  <li><strong>Just-in-time compilation allows for greater portability.</strong> Isn't that attributable to the intermediate format? I mean, nothing keeps you from compiling your virtual bytecode into native bytecode once you've got it on your machine. Portability is an issue in the 'distribution' phase, not during the 'running' phase.</li>
  <li><strong>Okay, then what about generating code at runtime?</strong> Well, the same applies. Nothing keeps you from integrating a just-in-time compiler for a real just-in-time need into your native program.</li>
  <li><strong>But the runtime compiles it to native code just once anyways, and stores the resulting executable in some sort of cache somewhere on your hard drive.</strong> Yeah, sure. But it's optimized your program under time constraints, and it's not making it better from there on. See the next paragraph.</li>
  </ol>
  
  <p>It's not like <strong>ahead-of-time</strong> compilation had no advantages either. <strong>Just-in-time</strong> compilation has time constraints: you can't keep the end user waiting forever while your program launches, so it has a tradeoff to do somewhere. Most of the time they just optimize less. A friend of mine had <em>profiling evidence</em> that inlining functions and unrolling loops "manually" (obfuscating source code in the process) had a positive impact on performance on his <strong>C#</strong> number-crunching program; doing the same on my side, with my <strong>C</strong> program filling the same task, yielded no positive results, and I believe this is due to the extensive transformations my compiler was allowed to make. </p>
  
  <p>And yet we're surrounded by jitted programs. <strong>C#</strong> and <strong>Java</strong> are everywhere, Python scripts can compile to some sort of bytecode, and I'm sure a whole bunch of other programming languages do the same. There must be a good reason that I'm missing. So what makes <strong>just-in-time</strong> compilation so superior to <strong>ahead-of-time</strong> compilation?</p>
  
  <hr>
  
  <p><strong>EDIT</strong> To clear some confusion, maybe it would be important to state that I'm all for an intermediate representation of executables. This has a lot of advantages (and really, most arguments for <strong>just-in-time</strong> compilation are actually arguments for an intermediate representation). My question is about how they should be compiled to native code.</p>
  
  <p>Most runtimes (or compilers for that matter) will prefer to either compile them just-in-time or ahead-of-time. As <strong>ahead-of-time</strong> compilation looks like a better alternative to me because the compiler has more time to perform optimizations, I'm wondering why Microsoft, Sun and all the others are going the other way around. I'm kind of dubious about profiling-related optimizations, as my experience with <strong>just-in-time</strong> compiled programs displayed poor basic optimizations.</p>
  
  <p>I used an example with C code only because I needed an example of <strong>ahead-of-time</strong> compilation versus <strong>just-in-time</strong> compilation. The fact that <strong>C</strong> code wasn't emitted to an intermediate representation is irrelevant to the situation, as I just needed to show that <strong>ahead-of-time</strong> compilation can yield better immediate results.</p>