New Intermediate Language Proposed

WillOutPower writes "Sun is inviting Cray (of supercomputer fame) and IBM (needs no introduction...) to join and create a new intermediate run-time language for high-performance computing. Java's bytecode, Java Grande, and Microsoft's IL language for the Common Language Runtime, it seems a natural progression. I wonder if the format will be in XML? Does this mean ubiquitous grid computing? Maybe now I won't have to write my neural network in C for performance :-)"

Comments

Re:Didn't we do this once before?

[VertigoAce]

One interesting feature of .Net is language interoperability. Someone can write a class in VB.NET and I can inherit from that class in C++ just the same as if the original was written in C++. Sure there were ways of doing this before, but you generally had to treat other components in a different way from stuff written and compiled in your current project's language.

A more typical usage would be to write anything that needs better performance or that needs access to non-.net libraries in C++ (since it can be compiled to machine code before distributing) and then use that component in other languages that are easier for putting a GUI together. Again, it's always been possible to do stuff like this, but .NET makes it seamless (it's just like linking to any other library).

If you've not implemented parallel code X-Arch

[fw3]

Then you (like the pos(t)er of this article and most of the comments) probably don't follow what the value is here.

Maintaining high performance code across cpu achitectures is bad enough (and I know of some supercomputing centers which are continuing with technically inferior AMD64/Xeon clusters rather than switch to PPC970 precisely because they know they can't afford to re-optimize for that arch).

Factor in that today most numerically intensive code is still written in FORTRAN because competing languages simply can't be as easily optimized.

Now let's think about SMP, while POSIX threads are portable, the best performace probably requires different threading code depending on arch/unix varriant. (And of course NPTL for linux is still in CVS.)

Now let's think about massively parallel, where inter-cpu communication will be handled a bit differently on every platform.

So the payoffs to developing an efficient cross-platform language layer are pretty substantial. (Which does not imply that I expect IBM to jump on to Sun's bandwagon on this :-))

Re:Next try?

[kingkade]

Ok, so now that Java is on the retreat they try to enter a new area?

It's probably because there's no Java user community or usefull implementations out there. And it has virtually no practical application on the desktop for that matter. Maybe because it doesn't do 3D or sound. Or is not so usefull as far as scalable RDBMS abstraction or a real application server for the enterprise. Maybe they need to move into the mobile market. What's really needed is a good Java IDE to get developers on board. Changes should be driven by the software community and making the source open would help as well. Sun should also be making improvments in Java's next(?) version.

You're right, I guess "we" should just cut our losses.

Re:Buzzword compliance

[Elian]

Nah. we put that in to not scare people. Parrot is, for all intents and purposes, completely independent from Perl 6 and has been for ages. (well before that article was written). While we're going to put in anything we need to make perl 6 run on parrot, the same can be said of anything we need to run Python and Ruby. (Which has already happened, FWIW) The only difference is that Matz and Guido haven't asked for anything yet...

Compilers 101

[p3d0]

I don't understand your question, but if you're asking why we need intermediate languages, then I can answer that.

Imagine N high-level languages and M target platforms. A naive approach would wind up creating NxM separate compilers.

Intermediate languages (ILs) allow you to write N "front-ends" that compile the N high-level languages to the IL, and M "back-ends" that compile from the IL to the M target platforms. So rather than needing NxM compilers, you only need N+M.

Even more significant is the optimizer. Front-ends and back-ends are relatively straightforward, but optimizers are very hard to write well. In the naive approach, you need NxM optimizers. With an IL, you only need one. The front-end translates to IL; the optimizer transforms IL to better IL, and the back-end translates to native code.

In summary, to answer one of your questions:

What's wrong with making a good compiler that writes directly to machine code?

Every optimizing compiler uses an IL anyway. These companies, I presume, are simply agreeing to use the same IL across their products (though I'm only guessing because the article is slashdotted).