Re: Made compiler/now how to make interpreter faster?

swoo@pobox.com writes:
> What are good sources for information on how
> to change the bytecode stream/interpreter/compiler for the fastest
> executing code?


That depends on where the system spends its time, and where the
inefficiency comes from.


If the system spends a lot of time in interpretation overhead, using
threaded code (see
http://www.complang.tuwien.ac.at/forth/threaded-code.html) would
provide a good speedup; you could also combine frequent combinations
of virtual machine instructions into new virtual instructions (see
proebsting95). You can also add virtual machine instructions
specialized for certain in-line parameters (e.g., add1 as specialized
version of addi (add immediate)), thus eliminating the time to access
these parameters in memory. Or you may want to improve the compiler so
it generates fewer instructions.


If, OTOH, your virtual machine instructions are quite heavyweight,
going the RISC way can lead to speedups: add simplified versions of
your instructions for frequent special cases, and make your compiler
more sophisticated to generate these simpler instructions.


> Compared to plain C code the interpreter is much much
> slower, about 50-100x for a repeated loop, which seems pretty poor.


Just to give you an idea, for small benchmarks like the sieve,
hand-written Forth code running on the Gforth interpreter is 4-8 times
slower than hand-coded C compiled with gcc -O3, on various machines.


- anton


@InProceedings{proebsting95,
    author = "Todd A. Proebsting",
    title = "Optimizing an {ANSI~C} Interpreter with Superoperators",
    crossref = "popl95",
    pages = "322--332"
}


@Proceedings{popl95,
    booktitle = "Principles of Programming Languages (POPL '95)",
    title = "Principles of Programming Languages (POPL '95)",
    year = "1995",
    key = "POPL '95"
}
--
M. Anton Ertl
anton@mips.complang.tuwien.ac.at
http://www.complang.tuwien.ac.at/anton/home.html
--

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