Daniel O'Connell [C# MVP]
12/21/2004 10:22:00 PM
"#pragma once" <itismedude__@e2hotmails.com> wrote in message
news:eS8AfW15EHA.3376@TK2MSFTNGP12.phx.gbl...
> That's all we are expecting from programs written in the managed code;
> Though a MVP advised not to say that, because after JIT compilation the
> code runs in the native! Funny, isn't? That means scripting languages run
> in
> the Host code and never in the native? That means scripting languages
> are poorer than .NET in speed just because they are hosted by an
> interpreter? What about .Net run time libraries? Can any one tell me the
> differences? (my JavaScript loops are some times as fast as their C#
> or VB.NET counterparts under IE6!, just not mentioning their GDI
> performance....)
> What is the difference between an interpreter and a VM ?
> ( If you call .NET VM NOT an interpreter after all).
The primary difference between an interpreter and a VM is considerable, and
I don't think its the question you actually meant to ask.
A VM is a virtual machine, and in this context is an abstraction of memory
model, execution model, and potentially other bits like port IO and devices,
depending on the complexity of the machine, that is designed to allow
programs to run across multiple platforms without recompilation or
re-writing. An interpreter is a piece of code that reads and executes code
(usually a script, but it can be compiled machine code as well).
What you mean, I think, is the difference between an interpreter and a JIT.
A VM can execute code using either an interpreter or a JIT compiler. Java,
..NET and I think javascript all have a VM(and they aren't the only
languages\runtimes). The primary difference is how they execute code.
The Microsoft .NET VM doesn't have an interpreter(atleast that I can think
of off hand), it, like modern java, uses a JIT compiler. Mono provides one
and I believe older java versions were interpreted.
To my knowledge, javascript is interpreted in a web browser as JIT
compilation is pretty useless for script that is going to change that often.
Thus most simple scripts are not JIT'd, but a scripting language is not
precluded from being JIT compiled if the script executer supports it
Now, the difference betwee the two is simple. An interpreter reads and
executes instructions directly. For example it would read a command out of
the script file, determine what it says to do and execute it, generally by
calling functions within the interpreter itself(1+2 may result in a Add(1,2)
call in the interpreter for example). A JIT compiler takes the script file
or encoded instructions(usually encoded instructions), analyzes them, and
emits normal machine code which the processor executes directly.
There are tradeoffs between the two, interpretation is potentially easier to
write(I'd be unwilling(and probably unable) to do a script code to native
JIT, although I have written scripting code to MSIL JIT before), it is also
considerably faster for short scripts like much javascript code as JIT has a
longer startup time(in general atleast an entire method has to be compiled
before execution, while scripts execute line by line).
JIT's will produce faster code in many to most cases(especially mathematics
or memory access heavy code), with a slower startup and more memory
required(uncompiled code, compiled code, and transition structures have to
be stored for atleast a period in time). JIT'd code doesn't have the call
overhead of the interpreter, making execution pretty close to machine speed
once JIT compiled.
In theory, also, a JIT can emit instructions and instruction sequences that
are highly optimized for a specific machine that will significantly outrun
interpreted code, but not all JIT's are at that level.