At 12:53 PM +0200 6/9/02, Jerome Vouillon wrote: >On Sat, Jun 08, 2002 at 03:54:06PM -0400, Melvin Smith wrote:
>The Java bytecode interpreter is clearly not optimized for speed. >David Gregg, Anton Ertl and Andreas Krall have experimented with an >improved Java bytecode interpreter. One of the optimisations they >perform is to get rid of this copying. Overall, they get a factor 5 >to 10 improvement on some JavaSPEC benchmarks over other Java bytecode >interpreters. >(See "A fast Java interpreter" and "Implementing an efficient Java > interpreter" from http://www.complang.tuwien.ac.at/papers/ > By the way, Anton Ertl has written a lot of other very good papers on > bytecode interpreters.) Right, the Java folks always planned for a JIT, or at least a rewrite, and didn't spend that much time optimizing the initial interpreter. Which, honestly, we're doing too. > > >Yeah, that's too much work for me. I'd rather do something simpler, even >> >if that boils down to "we return a single ParrotList with all the return >> >values in it, stuck in P0". > >Yes, that would be fine. We can still optimize this later if >necessary. The paper "An Efficient Implementation of Multiple Return >Values in Scheme" by Ashley and Dybvig present a possible >implementation. >(http://citeseer.nj.nec.com/ashley94efficient.html) Yeek. On initial read, that just screams out "Huge Hack". That might just be the Scheme bits, though. :) Some interesting ideas. I'll have to think about it some. -- Dan --------------------------------------"it's like this"------------------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
