Dan Sugalski wrote:
At 5:36 PM +0100 2/8/03, Leopold Toetsch wrote:
[ threaded JIT/prederef ]
Ouch, yes. So does JIT. So JIT/prederefed code must be separated for threads.
Yup. This was a decision made a long time ago, back when Daniel started the first JIT stuff.
Not necessarily so now, it seems. Adressing registers by (thread + index), as outlined in Jerome's recent reply to the YARL (switched run loop) thread is equally fast on e.g. I386. Dunno if other $arch has a similar addressing mode. But as all recent processors now are (very) pipelined, one extra argument in the op stream only increases code size but not execution speed.
... (And that was before everyone got it going insanely fast :)
Thank you Sir.
It's one of the reasons I haven't been too worried about speeding up the core loop. I've been figuring we'll end up with three:
*) JIT
*) CGoto
*) Old indirect dispatch
The fastest are in terms of possible $arch/compiler features now: - JIT - CGP (makes CGoto obsolete) - Switched Prederef (not in CVS) but plain function call is needed e.g. for JIT - now.
and leave it at that. When Gregor was working on the prederef I figured we'd use it as the third, since the JIT was new and I wasn't sure it'd be possible to get it as a good general solution, but it's developed so much that I'm not sure it's worth more loop development. (I could, of course, be wrong... :)JIT (known as that acronym, but isn`t just in time in parrot) is a very $arch depend feature. I did speed up mul_i_ic by 2-50 for some constants today, which a different $arch doesn't yet have implemented.
The CGP core is really fast for all compilers that have computed goto - and honestly, the code that HL emit, will resemble much a code that is not well suited for JIT.
The optimizer in imcc is the real *challenge* in the whole story.
leo
