Dolphin, the GameCube and Wii emulator - Forums

I know there's a shader cache (and a temporary texture cache). But has anyone experimented with AOT vs JIT and determined whether it would be feasible to cache native blocks. 

What are the difference between AOT and JIT in your opinion? Especially for emulators?

(02-20-2015, 06:20 PM)degasus Wrote: [ -> ]What are the difference between AOT and JIT in your opinion? Especially for emulators?

I feel like if the emulator is consistently running the same code for a game (persisting through multiple start ups) that there's no reason for identical code to be emulated again when you have the native code all ready.  In theory it could work for emulators as AOT works with VM code which is a semi-similiar idea.  Having an effective "code cache" could save a ton of CPU time,  at the expense of disk space from caching a rather huge amount of code.  IN theory it should be reliable and doable,  because Nvidia's Denver architecture code caching can cache large chunks of dolphin code successfully,  so it stands to reason that there's definitely repeat code instances that code be optimized through caching (either to ram for temp cache or disk for more permanent caching).

I don't think so, our ppc jit is very fast so caching the native objects doesn't help much. But however we have issues because of shader comilation, but they are already stored on the disc.

Has anyone ever attempted a Tracing JIT in an emulator?

(02-20-2015, 09:52 PM)degasus Wrote: [ -> ]I don't think so, our ppc jit is very fast so caching the native objects doesn't help much. But however we have issues because of shader comilation, but they are already stored on the disc.

Well in theory if you make a large enough cache,  you could have an entire game's worth of code compiled and basically not need the JIT,  and rely entirely on AOT-like behaviour to simply run an almost entirely native program.

Maybe I'm just trying to think too far outside the box.

Dolphin's JIT is incredibly fast; the time spent in it is hard to measure with typical profiling tools because it's basically a rounding error. If you were using a vastly more heavyweight compiler, maybe it could be an issue?

A tracing JIT definitely sounds like an interesting idea, but on a system that can arbitrarily swap out code in memory, the question of "what do I do to a trace when part of it gets invalidated" could be difficult. Plus, code size is already a big problem, and tracing JITs are known for that.

It's not impossible though; I do really like the idea of tracing as an approach. The first tracing JIT ever was actually for emulation/recompilation, not for compiling an existing language, despite the commonness of tracing JITs in Javascript and such today.

(02-20-2015, 11:30 PM)Nintonito Wrote: [ -> ]Well in theory if you make a large enough cache,  you could have an entire game's worth of code compiled and basically not need the JIT,  and rely entirely on AOT-like behaviour to simply run an almost entirely native program.

This is the common case while being ingame. Just on loading a new level, we start to jit the next blocks again.

Just as a note, compiling AOT doesn't mean the result will run faster.

(02-21-2015, 01:40 AM)Fiora Wrote: [ -> ]Dolphin's JIT is incredibly fast; the time spent in it is hard to measure with typical profiling tools because it's basically a rounding error. If you were using a vastly more heavyweight compiler, maybe it could be an issue?

A tracing JIT definitely sounds like an interesting idea, but on a system that can arbitrarily swap out code in memory, the question of "what do I do to a trace when part of it gets invalidated" could be difficult. Plus, code size is already a big problem, and tracing JITs are known for that.

It's not impossible though; I do really like the idea of tracing as an approach. The first tracing JIT ever was actually for emulation/recompilation, not for compiling an existing language, despite the commonness of tracing JITs in Javascript and such today.

So the feeling I'm getting is that its a waste of time because the code won't be any faster,  unless the CPU emulator was someone completely rewritten with a tracer in mind.  Makes sense.  I guess i sort of underestimated the speed of the existing JIT.  Still,  tracer JIT's are a wonderful concept,  and I kinda wish we saw more of them (I personally would be willing to trade disk/ram space for a worthwhile speed up.  Especially since I have all this RAM in my computer that never gets used.)