Related articles |
---|
Interpreters & Intermediate languages elan@tasha.cheme.cornell.edu (1994-04-13) |
Re: Interpreters & Intermediate languages pardo@cs.washington.edu (1994-04-13) |
Re: Interpretersn & Intermediate languages pardo@cs.washington.edu (1994-04-14) |
Newsgroups: | comp.compilers |
From: | pardo@cs.washington.edu (David Keppel) |
Keywords: | interpreter, translator, comment |
Organization: | Computer Science & Engineering, U. of Washington, Seattle |
References: | 94-04-092 94-04-094 |
Date: | Thu, 14 Apr 1994 22:47:57 GMT |
>>[Discussion of instruction set simulators.]
John Levine (compilers-request) says:
>[I know many systems translate to machine code; what would astonish
> me is if you got usefully fast performance (compared to a decode and
> dispatch interpreter) by compiling to something other than machine
> code.]
I suppose it hinges around what you consider to be `usefully fast'.
- One fast decode-and-dispatch interpreter in assembly averages
around 40I/I and peaks around 30I/I.
- Rob Bedicheck's `g88' simulator is written in C and does
compilation to threaded code and even though it does much more
simulation work (address translation, etc.) it averages better than
30I/I, peaks at better than 20I/I and could probably be streamlined
down to 10I/I if you removed a lot of the fancy features (address
translation, etc.).
- Several systems that translate to machine code peak at around 2I/I.
A factor of 2-3 improvement by dynamically compiling to threaded code
seems ``usefully fast'' to me, but it does depend on your needs.
These figures aren't exact because the host and target machines vary,
but there are several implementations in each camp, and the relative
performances of various host/target combinations and implementation
technologies seem to be fairly consistant.
;-D on ( Pidgin intermediate langauges ) Pardo
[OK, OK, I'm astonished. -John]
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.