Tratt: Fast Enough VMs in Fast Enough Time [LWN.net]

Tratt: Fast Enough VMs in Fast Enough Time

Posted Feb 10, 2012 23:35 UTC (Fri) by daglwn (subscriber, #65432)
In reply to: Tratt: Fast Enough VMs in Fast Enough Time by khim
Parent article: Tratt: Fast Enough VMs in Fast Enough Time

That's sometimes true, but not usually.

HP's Dynamo project had great success JITing PA RISC code to PA RISC code. What's the point? They had access to values at runtime that they did not at static compile time. They were able to delete branches and optimize very large basic blocks such that the resulting code ran fast enough to more than overcome the overhead of the translation.

This code could not be generated at static compile time because the program input is not available then. Even if you can predict a static path at static compile time (doubtful) you still don't have the actual data values to take advantage of.

DEC's FX!32 and IBM's DAISY were similar projects.

They weren't tracing JITs but they could just as well have been.

(Log in to post comments)

Tratt: Fast Enough VMs in Fast Enough Time

Posted Feb 11, 2012 12:44 UTC (Sat) by khim (subscriber, #9252) [Link]

This code could not be generated at static compile time because the program input is not available then. Even if you can predict a static path at static compile time (doubtful) you still don't have the actual data values to take advantage of.

You have a point. P4 was purely tracing JIT and contemporary CPUs dropped that approach because it's hard to combine both in a single chip.

As P4 story shows pure tracing JIT is a disaster and will probably always be a disaster. But combination or regular JIT with tracing JIT may sometimes make sense as was already pointed out. The question is: how often will it make sense?

DEC's FX!32 and IBM's DAISY were similar projects.

And here you are missing the point again. DAISY, Dynamo, FX!32 and IA-32 EL - they all play with architectures which explicitly tried to switch from JIT implemented in hardware to "intelligent compiler". This idea flew like a lead balloon. In the vain hope to save it they tried software JIT - but it does not work as well.

They weren't tracing JITs but they could just as well have been.

I'm not so sure. The general problem of tracing JITs (which killed NetBurst, too) will probably be fatal for these projects.

Now, the use of tracing JIT as "superbooster" for rare case may be interesting, but these projects never went so far.

P.S. Actually architecture of contemporary CPUs make work of JIT creators very frustrating. It's easy to show real-world case where JIT wins over pure static compiler. But since contemporary CPUs always use JIT we don't have a "JIT vs compiler" competetion. We have "“JIT+compiler” vs “JIT+JIT”" competition - and this combination rarely makes sense. Especially when two stacked JITs are created by different teams which don't cooperate at all.