Sean Kelly Wrote:

> Java runs on a VM largely because it allows proprietary applications to be run on any platform with a supporting VM. The alternative would be to distribute code in source form and have the user build locally, or to pre-build for every target platform (which is not always feasible).

I don't mind to do build for every target platform. There's a lot of I/O and CPU overhead initializing JIT compiler and compiling source runtime. Users are constantly complaining about start-up times. That's why Microsoft provided utility called NGEN which is producing native binaries of .NET bytecode so JIT compilation won't be needed. Whole .NET framework is practically NGENed during installation.

I understand JIT compilation is not going away, especially for dynamic languages such as Python but I'm not sure if we can really squeeze that much more from JIT compilation of statically-typed languages. If there are not going to be significant performance gains in comparison to running pre-compiled programs, then I suppose we're just adding one unnecessary layer and JAVA+.NET are going wrong direction.

I'm just looking for answers if JIT compilation for statically-typed languages is doomed or has any hope.

Lubos

lubosh wrote:
> Sean Kelly Wrote:
> 
>> Java runs on a VM largely because it allows proprietary applications to be run on any platform with a supporting VM. The alternative would be to distribute code in source form and have the user build locally, or to pre-build for every target platform (which is not always feasible).
> 
> I don't mind to do build for every target platform. There's a lot of I/O and CPU overhead initializing JIT compiler and compiling source runtime. Users are constantly complaining about start-up times. That's why Microsoft provided utility called NGEN which is producing native binaries of .NET bytecode so JIT compilation won't be needed. Whole .NET framework is practically NGENed during installation.
> 
> I understand JIT compilation is not going away, especially for dynamic languages such as Python but I'm not sure if we can really squeeze that much more from JIT compilation of statically-typed languages. If there are not going to be significant performance gains in comparison to running pre-compiled programs, then I suppose we're just adding one unnecessary layer and JAVA+.NET are going wrong direction.
> 
> I'm just looking for answers if JIT compilation for statically-typed languages is doomed or has any hope.

I don't think JIT as performed by Java and .NET makes any sense; it's performed far too late.
However, the fast fourier transform code in www.fftw.org is a stunning example of an alternative. It compiles several algorithms, and profiles each of them. Then it links in the fastest one.
You have to be able to JIT the algorithm; JITing the code generation step is useless.

Don Clugston wrote:

> I don't think JIT as performed by Java and .NET makes any sense; it's performed far too late.

You might be interested in this article:

http://www-128.ibm.com/developerworks/java/library/j-rtj2/index.html

lubosh wrote:
> Sean Kelly Wrote:
> 
> That's why Microsoft provided utility called NGEN which is producing native binaries of .NET bytecode so JIT compilation won't be needed. Whole .NET framework is practically NGENed during installation.
> 

Ah, interesting, so that's why the installtion of the the .NET framework takes a rather long time, mistery explained.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bruno Medeiros wrote:
> lubosh wrote:
>> Sean Kelly Wrote:
>>
>> That's why Microsoft provided utility called NGEN which is producing native binaries of .NET bytecode so JIT compilation won't be needed. Whole .NET framework is practically NGENed during installation.
>>
> 
> Ah, interesting, so that's why the installtion of the the .NET framework takes a rather long time, mistery explained.
> 

But what's truly ridiculous is that .NET has exactly *one* target platform.

-- 
- EricAnderton at yahoo

Pragma wrote:

> Bruno Medeiros wrote:
>> lubosh wrote:
>>> Sean Kelly Wrote:
>>>
>>> That's why Microsoft provided utility called NGEN which is producing native binaries of .NET bytecode so JIT compilation won't be needed. Whole .NET framework is practically NGENed during installation.
>>>
>> 
>> Ah, interesting, so that's why the installtion of the the .NET framework takes a rather long time, mistery explained.
>> 
> 
> But what's truly ridiculous is that .NET has exactly *one* target platform.

Hehe, on slashdot a 'you must be new here' reply would be modded +5 informative :P

Yeah, of course it makes sense. Let's abstract away the underlying hardware & operating system and lock people on this new highly portable platform with IP stuff, patents and DMCA. Problem solved.

It's interesting to see how much effort MS has put into .NET platform and language research (well, except Java for some unknown reason :P) lately. I don't think they will be giving it all away for free.

Jari-Matti Mäkelä wrote:
> 
> Yeah, of course it makes sense. Let's abstract away the underlying hardware
> & operating system and lock people on this new highly portable platform
> with IP stuff, patents and DMCA. Problem solved.

To be fair, Ms does target ARM as well, for its handheld devices. Though I wonder if those devices have a full .NET VM.  In any case, pre-generating binary code is obviously more efficient, so why not use it for a VM?  The original point of .NET is a COM replacement anyway, regardless of how things have been spun.

> It's interesting to see how much effort MS has put into .NET platform and
> language research (well, except Java for some unknown reason :P) lately. I
> don't think they will be giving it all away for free.

They have to.  The CLI is an open standard.  They may choose to sell their implementation of it of course, but they can't forbid anyone from implementing a compatible VM.


Sean

Sean Kelly wrote:
> Jari-Matti Mäkelä wrote:
>> 
>> Yeah, of course it makes sense. Let's abstract away the underlying hardware & operating system and lock people on this new highly portable platform with IP stuff, patents and DMCA. Problem solved.
> 
> To be fair, Ms does target ARM as well, for its handheld devices. Though I wonder if those devices have a full .NET VM.  In any case, pre-generating binary code is obviously more efficient, so why not use it for a VM?  The original point of .NET is a COM replacement anyway, regardless of how things have been spun.

I was a bit over dramatic. It might also be the only way to get rid of legacy x86 support, if ever possible.

Don't forget about PowerPC and IA-64. XNA lets you write games for the
Xbox 360 using C# and a custom C# Express IDE.

I think .NET is more of an effort to kill Java rather than replacing COM though.

On 5/3/07, Sean Kelly <sean@f4.ca> wrote:
> To be fair, Ms does target ARM as well, for its handheld devices.
> Though I wonder if those devices have a full .NET VM.  In any case,
> pre-generating binary code is obviously more efficient, so why not use
> it for a VM?  The original point of .NET is a COM replacement anyway,
> regardless of how things have been spun.

-- 
Anders

Pragma wrote:
> But what's truly ridiculous is that .NET has exactly *one* target platform.

Oh? So you're saying the optimized code coming out of the NGEN sequence for a P4 CPU will be identical to the code for a P3 CPU? And what about Itaniums (or any other CPU) running 64 bit? I'd pretty sure Microsoft is counting those variations as "platforms".

-- 
Joel Lucsy
"The dinosaurs became extinct because they didn't have a space program." -- Larry Niven