2 ms·
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 produ
by 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 agoMaybe - 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 agoAOT 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.