3 ms·

Yes! But it's important to keep in mind the sort of optimizations that JIT enables: monomorphic dispatch, type specialization, etc. And also what it's bad at: c

Yes! But it's important to keep in mind the sort of optimizations that JIT enables: monomorphic dispatch, type specialization, etc. And also what it's bad at: computationally expensive or memory-intensive operations, like graph-coloring register allocation. So generally speaking, we'd expect JIT to shine with certain branchy or unpredictable code, but static compilers to shine for basic blocks. Since the hot spot of the code in question is one big basic block (no if statements, etc.), where even the loop trip count is known statically, it would be surprising in this case if a JIT outperforms a static compiler.

vardump 12y ago
Yeah, it might be worse at allocating registers, but on the other hand it can often free registers as well. Static compilers just don't have the runtime information to take advantage of. Some maybe, by using profile guided optimization. JIT can always have profile guided, and adapt just for that particular case.
- ridiculous_fish 12y ago
  Right, but JITs only have the runtime information after a slower warmup period, and even then recording and exploiting this information has a cost too. The real divide here is between client/server: fancy JIT techniques can benefit long-running apps on beefy servers, but won't help a Java app launch faster on a smartphone.
  - vardump 12y ago
    There's absolutely no reason why there needs to be a warm-up period. You can cache the JITted binary code to disk. CPUs really don't care how the code was produced. A sampling profiler can be pretty cheap. Just record stack state every n milliseconds, no need to instrument everything. Actual JITting can be done on those other cores that would otherwise be idle anyways.
    - ridiculous_fish 12y ago
      Maybe - it sounds tricky though, since optimizations can be rendered invalid across runs (e.g. a plugin may be loaded that invalidates a monomorphic dispatch optimization). So you must track and re-validate the assumptions underlying the optimized code before it can be used. Also startup code is often executed once, and so is a poor candidate for expensive JIT optimizations. That said, in principle it seems like one could do as you say - it's just hard. Empirically, the industry seems to be moving from JIT to AOT, at least for clients. .NET -> Ngen, Dalvik -> ART, JavaScript -> asm.js, etc. (Oh, and it's a suspect assumption that there exists other cores that "would be idle anyways!")
      - vardump 12y ago
        AOT doesn't exclude JIT! Doing both is the winning combination. AOT will ensure fast start-up time and JIT will ensure optimization to runtime conditions. It's tricky I'm sure, but it'll happen.

vardump 12y ago

Yeah, it might be worse at allocating registers, but on the other hand it can often free registers as well. Static compilers just don't have the runtime information to take advantage of. Some maybe, by using profile guided optimization. JIT can always have profile guided, and adapt just for that particular case.

ridiculous_fish 12y ago
Right, but JITs only have the runtime information after a slower warmup period, and even then recording and exploiting this information has a cost too. The real divide here is between client/server: fancy JIT techniques can benefit long-running apps on beefy servers, but won't help a Java app launch faster on a smartphone.
- vardump 12y ago
  There's absolutely no reason why there needs to be a warm-up period. You can cache the JITted binary code to disk. CPUs really don't care how the code was produced. A sampling profiler can be pretty cheap. Just record stack state every n milliseconds, no need to instrument everything. Actual JITting can be done on those other cores that would otherwise be idle anyways.
  - ridiculous_fish 12y ago
    Maybe - it sounds tricky though, since optimizations can be rendered invalid across runs (e.g. a plugin may be loaded that invalidates a monomorphic dispatch optimization). So you must track and re-validate the assumptions underlying the optimized code before it can be used. Also startup code is often executed once, and so is a poor candidate for expensive JIT optimizations. That said, in principle it seems like one could do as you say - it's just hard. Empirically, the industry seems to be moving from JIT to AOT, at least for clients. .NET -> Ngen, Dalvik -> ART, JavaScript -> asm.js, etc. (Oh, and it's a suspect assumption that there exists other cores that "would be idle anyways!")
    - vardump 12y ago
      AOT doesn't exclude JIT! Doing both is the winning combination. AOT will ensure fast start-up time and JIT will ensure optimization to runtime conditions. It's tricky I'm sure, but it'll happen.