3 ms·
Given the nature of the JIT and the limited size of the translation cache (2 MiB IIRC), applications with huge code bases and little repeat rate (like browsers
by FullyFunctional 3y ago
Given the nature of the JIT and the limited size of the translation cache (2 MiB IIRC), applications with huge code bases and little repeat rate (like browsers and MS Word) will perform less well. The poster child for Crusoe was PowerDVD, but Quake had also gotten a lot of attention. Note, in those days there was a surprising amount of self-modifying code. That stuff is really nasty to deal with for a JIT. There was hardware support for detecting this on (IIRC) a 1 KiB granularity (because code was intermixed with data, making the latter look like self-modifying code).
- Symmetry 3y agoWhen NVidia adopted Transmeta's technology to target ARM instructions with their Project Denver they added a facility to just run native code for bits that weren't hot spots.
- FullyFunctional 3y agoEven though I'm not sure what you mean by "native", this not exactly my understanding. AFAICT, Denver added a hardware Arm instruction decoder. This greatly helps with the first part of the JIT and especially accelerates the interpreter.
- karteum 3y agohttps://en.wikipedia.org/wiki/Project_Denver https://en.wikipedia.org/wiki/Project_Denver : "Project Denver was originally intended to support both ARM and x86 code using code morphing technology from Transmeta, but was changed to the ARMv8-A 64-bit instruction set because Nvidia could not obtain a license to Intel's patents"
- rep_lodsb 3y ago"Self-modifying code" might be more common today than it was back then, given the popularity of managed languages that also use some type of JIT. Forcing the output of that JIT through another translation step would be really bad for performance. If Transmeta had survived, perhaps they could have added support for different instruction sets to run e.g. Java or .NET "natively".