Re: General byte-codes reference

Norman_member@newsguy.com (Norman Culver) wrote (abridged):
> You have to take into account various factors such as CPU speed,
> memory speed and cache size. I've been doing a series of experiments
> with interpreters hand coded in assembler for some of the latest
> processors. It is possible to fit an entire interpreter into the L1
> cache (64 KB) of a 1 Ghz AMD but it won't fit into the 16 KB cache of
> a Pentium III. The Pentium IV with 12,000 trace cache entries looks
> very interesting but I don't have one to play around with.


For comparison, there is a Microsoft Research paper "Finite-State Code
Generation" which talks about a JIT-compiler which fits in 8k of x86.
They claim the total time of JIT+execution is within 2-4x of typical
static compiler generated code.


    http://www.research.microsoft.com/~cwfraser/pldi99codegen.pdf


These kinds of results lead one to question whether interpreting
bytecode is worth doing at all. Interestingly, the bytecode for
Microsoft's new C# language was designed to be compiled, not
interpreted. I don't know but I assume it's design was influenced by
the paper.


    Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
            brangdon@cix.co.uk | And close your eyes with holy dread,
                                                            | For he on honey dew hath fed
  http://www.bhresearch.co.uk/ | And drunk the milk of Paradise."
[It's probably worth doing where the size of the application isn't worth
the extra effort to run a compiler, but I agree that JIT compilers can
work very well. -John]

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