[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Diversity - existence, value, and pursuit.



At 01:45 PM 12/2/01, Simon Cozens wrote:
>On Sun, Dec 02, 2001 at 01:03:43PM -0500, Shriram Krishnamurthi wrote:
>
>But on
>other hand, it's obvious that you can't get code running on a VM to run
>as fast as C.

Actually, it is no longer obvious to me that a VM is necessarily slower than
natively compiled code, except under certain circumstances (*).

The reason I don't think it's obvious is that I was part of a team that wrote
a high-performance emulator for the Symbolics Ivory-architecure Lisp Machine,
and the performance we got from an emulator was no more than about a factor
of two away from native code.  This was for a couple of reasons:
  (1) The Ivory instruction set is quite high-level, and includes such 
things as
    type checks and array bounds checks as part of the instruction.  This meant
    that a single Ivory instruction actually requires quite a few RISC 
instructions.
  (2) We managed to fit most of our emulator entirely in the chip's instruction
    cache, meaning that instead of an application suffering from both 
instruction
    and data fetch stalls, we suffered only from data cache stalls.  This meant
    that we ran most code, essentially, without stalls.  (To be sure, we
    optimized the hell out of our VM; the main instruction dispatch loop had
    an average execution of 11 instructions in 6 cycles on DEC Alpha, and
    if we had a "tail call" architecture, we could have done much better.)

The second point is very important in modern OO programs, whose instruction
sequences are very far from straight line.

I wonder what the thoughts of other people are about the asymptotic performance
we could expect from a highly-tuned VM engine.

(*) The certain circumstances all involved tight "inner loops" executing small
numbers of machine instructions, such as what would happen multiplying
two arrays.