Re: Efficient bytecode design and interpretation

  Michal Gajda <mg169780@zodiac.mimuw.edu.pl> writes:
>Up to now I
>only found Romer et al "Structure and efficiency of bytecode
>interpreters"(which is limited only to 4 VM designs) and vmgen
>documentation(vmgen is bytecode interpreter generator provided with
>gforth).


For those who don't know these:


@InProceedings{romer+96,
    author = "Theodore H. Romer and Dennis Lee and Geoffrey
M. Voelker and Alec Wolman and Wayne A. Wong and
Jean-Loup Baer and Brian N. Bershad and Henry M. Levy",
    title = "The Structure and Performance of Interpreters",
    crossref = "asplos96",
    pages = "150--159"
}


And vmgen can be found at:


http://www.complang.tuwien.ac.at/anton/vmgen/


You may also be interested in
http://www.complang.tuwien.ac.at/anton/tmp/interpreter-arch.ps (a
shorter version of this paper will appear at Europar'01 (under the
title "The Behavior of Efficient Virtual Machine Interpreters on
Modern Architectures")).


>PS I tried to catch some performance tricks by analyzing bytecode formats
>of Ocaml, and some lisp implementations. Still differences in timing and
>efficiency still seem to be plain magic :-).
>[For example - why GForth VM, with all vmgen'ed optimizations, performs so
>badly at "Programming Language Shootout" page?


(I assume you mean http://www.bagley.org/~doug/shootout/)


Does it? Looking at, e.g., the Fibonacci benchmark, the only
interpreter faster than Gforth is ocamlb, all the other faster
implementations compile to native code in some form or other (the page
lists java as an interpreter, but I believe it really is a JIT
compiler).


Note also that the gforth-0.5.0 does not use superinstructions yet
(and the current snapshot has the ability, but does not use them,
either). Moreover, you can get quite a bit of speedup/slowdown
depending on how you compile and run gforth (best on IA32: gcc-2.95,
configure --enable-force-reg, use gforth-fast for running).


>[It's been discussed before. My suggestion is that unlike the design for
>a physical architecture, there's little added cost to providing zillions
>of operators,


That's not universally true. We have seen slowdowns on the 21064a,
when adding superinstructions to a JVM interpreter. This seems to be
the result of an increase in instruction cache misses, possibly
combined with some indirect effects of the cache misses.


> and the more each operator does the fewer times you go
>through the interpreter loop, so a CISC design likely wins.


Vmgen supports profiling the VM interpreter and semiautomatically
generating superinstructions from the profile; superinstructions are
automatically generated when the appropriate sequence of simple VM
instructions is generated. In this context it may be more beneficial
to generate a sequence of simple VM instructions in a place and let
the combining be done automatically (and possibly in a better way)
than to generate a more complex instruction in that place.


- anton
--
M. Anton Ertl Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html

Return to the comp.compilers page.
Search the comp.compilers archives again.