.NET competes with java-script

  • Thread starter Thread starter #pragma once
  • Start date Start date
P

#pragma once

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).
 
Pragma,

You should have a look too the operaration codes of a (micro) processor.

It is inefficient to use those because mostly they will repeatedly be used.
(Think for that too a simple decimal Add while the processor does not have a
decimal add), and because of that productivity programs would be much to big
when they where all used every time again.

Therefore is already in the 70's decided to use intermidiate languages
(whatever name is given to that)..
Those are between the processorcommands and the compiled/builded source.

The less operations that the intermidiate needs to come to the real process
and the most efficient code that is created means how productive the
programs are.

Therefore that step between human and computer what an intermidiate program
in fact is, does a good job too increase speed.

I hope this clears it a little bit?

Cor
 
I think that what you are talking about has more to do with the conception
of speed rather than real speed. The number of operations a CPU can deal
with in the time it takes to do the transfer of a page from a web site is
such that it is the number of trips between the client and the server which
is important.

Given this Javascript has a place since if all you want to do is now show
more information on the page you can write Javascript to hide/show
information without needing the server. If you write server code to do the
same it will take longer (clock time).

This is true with PHP/JSP/ASP ... etc. The technology is simple in that it
builds HTML and sends it to the client. A developer may decide that it is
more efficient to send more information in the page and have Javascript deal
with it until it has to be posted back to the server or if they don't know
Javascript then every event will be handled on the server end.

It is the mix of server and client code that can give the user a rich GUI
experience and the better the mix the faster the display and hopefully a
more enjoyable time interacting with a web site.

Lloyd Sheen
 
#pragma once said:
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).
Click to expand...

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.
 
Back
Top