Slashdot Mirror
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 :-)"
Sun should have invited us GCC developers also to help out with this because most of us want a way to do Inter modular optimizations but we have the FSF looking over our shoulder on how we implement it, right now (the mainline) you have to compile all the source files at the same time to get IMA to work correctly and you have to say to produce an .o file first.
No wonder we have to keep making faster CPUs just to maintain the same performance. Is Java on a PIII or G4 any faster than hand-optimized assembly code on a 486 or 68030?
Soon we'll need a 10 GHz CPU just to be able to boot tomorrow's OS in less than 5 minutes.
The article is very light on details.
Huh?
So, how many languages are being proposed here? A new "low-level" one, plus a higher-level "technical computing language" designed to make the most of the lower-level one? Just what's so special about this new low-level language that requires a specific new language to get the "maximum benefit" out of it? I don't have to write in Java to be able to compile to the JVM bytecode. For that matter, I could write in Java and compile to some other assembly language.
New back-ends ("low-level languages," if I understand the article) are added to GCC all the time. We never needed to add a whole 'nother front-end just for them.
I suspect that the real situation is less weird, and the journalist got confused... or heck, who knows, maybe they're proposing half a dozen new languages. It's Sun, after all.
Odd. I wouldn't have thought you'd need to do that these days anyway.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
"There is no problem in computer science that cannot be solved by adding another layer of indirection."
Language neutral? Perhaps I'm just skimming your linked-to article too quickly, but this is what leapt out of the page at me:
"Parrot is strongly related to Perl 6... Perl 6 plans to separate the design of the compiler and the interpreter. This is why we've come up with a subproject, which we've called Parrot that has a certain, limited amount of independence from Perl 6." [emphasis added]
That certainly doesn't sound like it's been designed with language neutrality in mind. For what it's worth, MS's IL was designed with at least four languages in mind - VB.NET, C#, managed C++ and J#, and a couple of dozen others have been or are being ported to it, including Fortran, Cobol, Haskel, and (iirc) even perl.
As you say, the article is over two years old, so maybe they've changed their goals since then - but that article at least gives a very strong impression that Parrot is tied intimately in with Perl.
It's official. Most of you are morons.
Because a well-designed intermediate language will help optimization. Being somewhat higher-level than raw machine code, not yet having to worry about the specific details of registers and pipelining, makes it easier to perform higher-level optimizations because the IL can be more easily analyzed. And when you compile from IL to the target you will have just the same opportunities for platform-specific optimizations as if you had compiled straight from the source language.
The other benefits of using an IL are manifold. New languages can be implemented without having to write a compiler for each platform. New architectures can be supported without having to write compilers for each language.
I have a positive modifier on Troll. When I mod someone Troll their karma should go UP!
All good compilers use at least one intermediate language. It's practically impossible to do good optimizations otherwise, even on a single platform. For example, you want to inline functions if that would improve performance, but in order to determine whether it improves performance means that you need to look at things like register allocation, which depends on things like the machine code implementation of complex expressions; however, inlining a function needs to be done with the higher level information about flow control and the structure of the function call. So you basically can't do any of the interesting optimizations without a good intermediate language.
Furthermore, getting from the high-level langauge to the intermediate language is cross-platform, which means that any optimizations done at this level are then available to all of the code generators for different platforms; this code is reused across back-ends. It also means that you can support multiple front-ends with the same back-end, and make your C++ and Java automatically compatible by virtue of sharing an intermediate language, and they also both benefit from the same architecture-specific back-end.
There's no reason that having an intermediate language means that you'll stop compiling at that level and use an interpreter for the intermediate language to run the program. In fact, gcc always compiles its intermediate language into machine code, and it can compile Java bytecode into machine code as well. Modern JVMs compile the bytecode into native machine code when the tradeoff seems to be favorable, and they can do optimizations at this point that a C compiler can't do (such as inlining the function that a function pointer usually points to).
An intermediate language essentially pushes more of the skill into the optimizing compiler, because the same optimizing compiler can be used for more tasks. Also, if the compiler is used at runtime, it can optimze based on profiling the actual workload on the actual hardware. This is especially important if, for example, IBM decides to distribute a single set of binaries which should run optimally on all of their hardware; you run the optimizer with the best possible information.
I recall a system based on USCD Pascal. I also :-) Except it was slow. Well, on my Apple ][ it was good for the fastest code after Assembler. It only got catched when Z80 coprocessors with CPM and Turbo Pascal came en vouge. .... So you need a VM on your CPU server, able to execute encrypted bytecode, so hat you as owner of the CPU dont see what the code is calculating. BUT you, a CPU server, you dont want your system compromized, or the code of other clients compromized by any piece of code. ... probably where the VM is itself only "executed" code inside of a meta cotainer. That means modern VMs probably will extract core VM features like garbage collection and thread scheduling outside of the VM into a library, and every piece of code may "class load" its own garbage collection schema. Consider differnt garbage collectors per thread and not per VM. ....
I did really a lot of programming in UCSD pascal, and long UCSD p-code was the most wide spread operation sytem/virtual machine.
If you need performance write it in assembler or
use nicely optimized C.
Assembler loses all higher level abstractions, like inheritance, interface implementation, class relationships(relations, aggregations and compositions), thread synchronization. The same is true for C, besides that it is on source level not able to express higher level concepts. You might use assembler instead of C.
How do you optimize assemberl? The operation system, the non existing, but hypotetical VM, the loader, the processor, none of hem can optimzie "assembler". I mean: In Java Byte Code I have all the higher level abstractions of the system inspectable via reflection etc. In assembler I have nothing.
New bytecodes, able to express more higher level informations e.g. like prarallelization, or even this problem: consider you have an CPU server, consider you have code migrating to youor server, consider you want to trust that code, consider, the "owner" of the code does not want to trust you
Or, consider this, you want byte code as an mobile agent, similar to the scenario above, but it should be allowed to replicate over a GRID, but only under certain restrictions.
You want to optimize every replica at the VM where it is finally executed, to take an optimum of resources on that point. How do you do that in "assembler"?
Modern byte codes will be likely even closer to the constructs of the high level languages than byte code is. Resource allocation, object creation, class loading, higher level concepts, like delegation, parallelism, synchronization(on multiple mutexes probably), serialization, distributed(pervasive) computing, probably OODB support build in, probably a light weight EJB like execution environment, probably a 4 level hierarchy of VM, meta container, container and executed code
Well, I could continue for a day with improvements
What's the benefit to yet another
layer of abstraction?
The benefit is to optimze on that layer of abstraction and then to project/generate/assemble the optimzation down onto the machine layer(or the next lower layer).
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
For its time, UCSD Pascal was an excellent language and operating system. Its main problems were price and politics, not performance or technical issues. Many people, including myself, wrote software for it. The speed penalty of the p-code interpreter was offset by the compactness of p-code, which was important on the memory-constrained PCs of the time. UCSD Pascal, like other alternative operating systems of the period, could not compete with MS-DOS and PC-DOS, which sold for well under $100, on price.
Mea navis aericumbens anguillis abundat
Ah, come on, that is anything but not insightfull ... ... and so on for Smalltalk, Python, LISP ... ... which is wasting 80% of its die (and 80% of its resources, energy put inot its production, waste produced and released into the environment) to be "compatible" with some old 8086 invention.
What's wrong with making a good compiler that writes directly to machine code?
a) it wont run on my phone, because no one will port teh compiler
b) it wont run on my new internet enabled microwave, because no one want to port the compiler
c) it wont run on my cars electronic, as no one want to port teh compiler
d) it wont run on the next ESA space probe, the Venus Express, because no one want to port the compiler
and so on.
Whats wrong with having an ultimative VM designed and freeing all software developers from all porting issues for one and for ever?
Whats wrong with having an ultimative VM designed and freeing all hardware developers to be braked out by compatibility issues?
Come one, code geeks. Make a step into the future!! A 4 GHz Pentium is about 16 million times faster than my Apple ][ which I used 15 years ago. Why should I be burdened with coding habits over 20 years old? I dont want to write 10 to 100 lines of assembelr a day, because it expresses far less in terms of instructions than 10 to 100 lines of C. And I dont want to write 10 to 100 line sof C a day becaue it expresses far less in terms of instructions than 10 to 100 lines o C++
We need more different higher level languages and more VMs, as it is easyer to make a new VM than a new processor. We do not need more compilers for the same old languages just because one built a new processor somewhere
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Parrot looks like it will be a nice intermediate language for languages like Python, Perl, and Java. But Parrot lack the right primitives for an intermediate language for high-performance numerical computing.
Right now the only widely used intermediate language that comes close to being suitable for high-performance numerical computing is Microsoft's CLR (JVM actually still has better implementations, but it lacks important primitives like value classes).
Java is on the retreat??? Wow, I've been gainfully employed as a Java architect for the past five years; it musta' been a fluke. IBM, Oracle, Novell, et al must not know what their doing by investing millions in building their products around the Java platform. Come to think of it, there are sooo many alternatives to Java for enterprise, server-side computing. Thank you for your insight. I'll turn in my resignation and pick up a .Net book tomorrow.
Xenon, where's my money? -Borno
In terms of compiler optimisation, the higher the language the better. Strict typing and a language that allows the compiler to infer more about the call tree should enable better global optimisation. Lower level languages suffer from the problem that the programmer is explictly describing how to do something, and not what it is trying to do; thus the compiler can just unroll loops and perform peephole optimisations.
If a language was sufficently high enough that you could describe to the compiler that you were implementing a recursive function (e.g. shell sort), the compiler should then be able to perform fold-unfold optimisation and convert the code into a more efficient tail iterative function. Fans of Haskell and similar languages might recognise this. Some C compilers will convert recursion to iteration where possible, but this is only in simple cases.
The fact is that today, even as C has reached maturity and as high level as it is, there are still some optimisations that are impossible because of subtleties of the language. For example, multiple pointers may point to the same memory, but depending on how the pointers are assigned, the compiler has no idea that this is the case, and has to follow the code in a literal fashion.
My personal view is that languages like Java still have a lot to offer. I would like to see a lot more investment in the compiler to perform better optimisations, and would also like to see a compile on install system for Java like C#; if I run an applcation it would atleast be nice if the compiled parts were cached somewhere. This I believe could make good performance gains, and it's interesting that Sun's Server Hotspot VM actually performs more optimisation when compiling a class than the Client VM, however, because of the increase in time taken to load and compile a class, the Client VM omits some optimisation techniques to favour speedier loading. I guess this descision is to make GUI's more responsive and reduce app load times; compile at install would remove this constraint. We should be going to higher level languages, not lower, and concentrate on getting to compiler correct.
-- Mike
Sure, as long as your class looks just like a C# one. Need multimethods, dynamic class redefinition, method combination, a non-crippled model of multiple inheritance, or maybe even prototypes? You're out of luck, because for this interoperability to work, your classes will either have to be C# classes or you have to make them look like ones, and .NET doesn't give you a Meta Object Protocol to do it.
In the great CONS chain of life, you can either be the CAR or be in the CDR.
I think what he's saying is that the syntax isn't the only thing that defines a language. A language's type system probably plays a more important part in defining how the language works.
With .Net, it may seem like you have a lot of interoperating languages, but they're all basically the same language with different superficial characteristics. VB developers complain about how VB.Net is totally different from previous versions of Visual Basic. It's because they gutted its internals and implanted C#. I wouldn't be able to tell the difference because I see similar syntax, but someone who really knows the language will detect a different core.
That's not to say that different type systems cannot be emulated. Nice is a language with Java-like syntax but with a much better type system (among other things) and it still runs on an ordinary JVM. However, any interoperability will have to be at the level of the lowest common denominator. If you want to call Nice code from Java, your interface ends up losing or having to give up some power.
You really can't even share libraries between truely different languages. The STL just doesn't fit into the Java/C#-style type systems (though generics is a step towards accomodating the STL). Perl libraries are also distinct. Imagine dealing with a Haskell-style lazy list in your C# code. It just wont feel right.
Unless you really need to use every cycle, you're better off writing in a high level language and then recoding the critical portions (as identified through thorough profiling) in assembly language. (I speak as one who needed to use every cycle when I was a games programmer in the 80s. I've often thought of doing an all-assembly, no OS required app today, just to see how ludicrously fast it would run.)
You gain extensive experience with the procesor and platform to which you are writing, and you work bloody hard. It also depends on whether you are optimising for space or speed. For example: writing a game for the Amiga, I was told by the customer that it had to run on machines with half a meg of RAM (the entry-level machine). I once spent a whole day seeking a way to save 12 bytes; the first part of the solution involved recoding a routine using a different algorithm. The rewrite saved me 8 of my 12 bytes, and executed in the same number of clock cycles (that was a crucial constraint). I then got the other four bytes by using the interrupt vector for an interrupt I'd disabled. As I was writing to the silicon (not even using any ROM routines), I could get away with this. I wonder what kind of warnings a modern C++ compiler would throw up for this kind of behaviour ;-)
Assembly language is fun, but life can be too short. I had to spend so much time fitting the above-mentioned game into half a meg that, by the time it came to market, 1Mb was the standard required by all games anyway.
If you design your code well you have plenty. Even when you inline code to save the overhead of call/return, you will be aware of the functional purpose of those 50 instructions considered as a single entity. The same discipline required to write well-constructed code is needed for assembler. It's similar to using an old version of BASIC, with only GOTO and GOSUB for transferring control; although it allows the sloppy thinker to produce spaghetti code, a good coder will adhere to the same abstractions as they would use in a higher level language.
I'll stop rambling about the past and go and write myself a Forth system now :-)
(P.S. p-code was extremely cool. When I first got acquainted with Java, it was the first thing I thought of. Plus ca change, plus ca ne change pas...)
Using HTML in email is like putting sound effects on your phone calls. Just say <strong>no</strong>.