Dan Sugalski wrote:
At 12:13 AM +0100 2/15/03, Leopold Toetsch wrote: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.
Right, but that's something that'll get slowly phased out as the JIT gets more mature and more opcodes get JITted. There's also the potential for the JIT to get really aggressive, if we can find folks with both the talent and the time to do it.
Honestly, if every $arch has every op JITted, we don't need anything else, when speed matters. But this will not happen - or not in the next some years.
Ok, predereferencing is not memory friendly, but its fast. JIT is a memory hog too as code gets unrolled as in the native C implementation done by pbc2c.pl. JIT/i386 currently estimates arena size as 10 * PBC size, which might be far to little for heavy access of vtable funcs.
1) Plain function dispatch
2) Switch core (for compilers with no computed goto)
3) CG core
4) JIT
with only the JIT allowed to rewrite the bytecode stream that it executes.
I think, we currently have far to few experience on real world programs to take some preferences. We only know, that different $arch/$compiler wont have CGoto or JIT.
A prederefed core still is much faster than one without, so this might even be a compile option (-Os vs -Ot).
Having said that, if the core building is completely automatic, and we can find an easy way (i.e. one that requires very little programmer thought and effort) to build and test any random collection of cores, I'm OK with that.
It is, except of JIT of course. I could add ny prederefed CSwitch core and it would build and run "make quickfulltest".
I think, that all the design issues are not that much sorted out, that we could decide, this core will be best for that real world program.
leo
