Interpreter speedup possible?

Tim Rowledge tim at sumeru.stanford.edu
Fri Aug 11 15:33:51 UTC 2000


In message <B5B8A5FB.48F6%Henrik.Gedenryd at lucs.lu.se> you wrote:

> The following described the Dolphin interpreter:
[snip]
> Could this have any significant impact on Squeak? It would seem relatively
> easy to trick this with the Slang inliner.
Squeak already does the next bytecode fetch within each bytecode code.
Using threading is a little harder since you have to have an array of
the bytecode adresses rather than a switch statement. Gcc can directly
provide suitable addresses and most compilers can be conned into it. You
also have to index off this array which means loading the array address
unless you have enough registers to keep it around.

Oddly enough, Ian's first released attempt at a jitter for Squeak did
the array of addresses stuff and used it to build a threading list asa
translated compiled method. It was a little faster on some some machines
and a little slower on others - I seem to recall something wrong with
the caching of the translated code. Could a simple threader make any
improvement? Dunno. Ian says that J4 shouldbe around soon, so itmay not
be worth the effort.

My opinion, for what it's worth, is that one of the biggest single
performance boosts comes from a cleverer context handling system.
Eliot's BrouHaHa had a simple but clever context & stack mechanism that
probably tripled _real_ performance; i.e. it wouldn't change the
Integer>pointlessBytecodesPerSecondBenchmark but would make a big
difference to 'normal' code. Ian is almost certainly using a similar
scheme in the jitter stuff; in fact there was one in the very first
jitter release.

tim

-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
"Bother," said Pooh, as the doctor diagnosed Syphillis.





More information about the Squeak-dev mailing list