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 :-)"
Mountain View, Calif. - Sun Microsystems is inviting competitors IBM Corp. and Cray Inc. to collaborate on defining a new computer language it claims could bolster performance and productivity for scientific and technical computing. The effort is part of a government-sponsored program under which the three companies are competing to design a petascale-class computer by 2010.
Sun's goal is to apply its expertise in Java to defining an architecture-independent, low-level software standard - like Java bytecodes - that a language could present to any computer's run-time environment. Sun wants the so-called Portable Intermediate Language and Run-Time Environment to become an open industry standard.
The low-level software would have some support for existing computer languages. But users would gain maximum benefit when they generated the low-level code based on the new technical computing language Sun has asked IBM and Cray to help define.
Whether IBM and Cray will agree to collaborate on the effort is unclear. Both companies have their own software plans that include developing new languages and operating systems as part of their competing work on the High Productivity Computing Systems (HPCS) project under the Defense Advanced Research Projects Agency (Darpa).
"We think languages are one area where the three of us should cooperate, not compete," said Jim Mitchell, who took on leadership of Sun's HPCS effort in August.
Last week Sun proposed to IBM's HPCS researchers they pool separate efforts on such a software language, an idea Sun said Darpa officials back. Sun also plans to invite Cray into the effort. Representatives from IBM and Cray were not available at press time.
The language could be used not just for the petascale systems in the project, but for a broader class of scientific and technical computers.
"Java has made it easy to program using a small number of threads. But in this [technical computing] world you have to handle thousands or hundreds of thousands of threads. We need the right language constructs to do that," Mitchell said.
- Kaos games and encryption systems developer
Javagrande.org
That format could be extended into a vendor-neutral format for both interpretation, just-in-time compilation, and batch compilation.
I believe CLR is supposed to be portable like Java, but functions are compiled to machine level code upon their first call. Of course there are no performance comparisons out there vs Java, because part of the EULA is that you will not publish any. :P
Architectural Neutral Distribution Format has been around for years and solves many of the same problems (and more).
I guess it is one more time around the (reinvention) wheel for sun.
omething akin to writing 'machine code' directly for a Java VM to optimize your application instead of just writing the darn thing in C, compiling it to the three platforms it's going to run on, and getting a 300% speed boost.
Can you provide any evidence for the quoted 300% speed boost? I code Java for a living, and ignoring the JVM startup hit (how often do you start and stop the sort of app you'd write in Java anyway?), it's anything but slow.
It's official. Most of you are morons.
Now, in all honesty, I still think it's a lemon, but it's not quite as limited (or intended to be limited) as you suppose it is.
I just wish IFF had survived the death of the Amiga as a mainstream platform.
You are not alone. This is not normal. None of this is normal.
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.
.NET makes it seamless (it's just like linking to any other library).
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
Java is still alive and doing well.
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 :-))
Linux is Linux, if One need clarify their dist: <Dist>/GNU Linux
bsds are of course just BSD
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.
why run from Vincenzo?
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...
Well considering Java's startup time removes it from all manner of applications, it's a bit of a strawman to argue that startup time doesn't matter.
*cough* *cough*
Bullshit
Bullshit
Bullshit
Bullshit
Bullshit
Bullshit
Bullshit
Please take your bullshit trolling elsewhere. There are those of us with work to do.
Javascript + Nintendo DSi = DSiCade
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:
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).Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
Well, the .NET framework gives you lots of appropriate choices. VB.NET and managed C++ can share objects with C#, for example. You can also define classes in VB.NET or managed C++ or whatever and use them in C#. There is a standard for the size of various data types in this framwork (ints, floats, chars, etc), so you don't have to worry about data loss or funny conversions when using data from a class written in a different language.
====
Crudely Drawn Games
You need Forth - possibly the only language where you make up the language as you go along.
Example of the Forth definition for the "make everything explode because the time or energy has run out" routine in a game I wrote years ago:
: kill_everything ( - )FWIW, "bursts" was a convenience word used to make it read better. Its definition was:
: bursts (thing_to_burst - )(The bits in brackets are stack diagram comments. The argument "thing_to_burst" is actually the address of the data structure representing the animated entity,)
By judicious use of the English language in choosing your names, you could write what people thought was pseudocode, and it compiled and ran :-)
Using HTML in email is like putting sound effects on your phone calls. Just say <strong>no</strong>.
You are quite right that current JVM implementations will outperform CLR implementations on comparable code. That's not surprising since JVMs are far more mature.
But that is only true for comparable code. If you write C# code using value classes and do an idiomatic translation into Java, the Java code will run very slowly because you cannot express something like a value class efficiently in Java. It doesn't matter how good the Java JIT is, it just can't optimize things that the JVM doesn't let programmers write down.
And the advantage that JVM JITs have on the more limited functionality they offer is likely short-lived: give CLR implementations another year and they will equal the JVM on their common subset of instructions, and they will still have the advantage of their additional primitives.
Note that Sun is not talking about extending the JVM anyway; this sounds like it's going to be a new and incompatible virtual machine from Sun.