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

I bet the format turns out to be...

[Anonymous Coward]

...binary.

Re:I bet the format turns out to be...

[JPriest]

With that many buzz words thrown out in just the into it MUST be good.

Re:I bet the format turns out to be...

[btakita]

Hey...If Seymour Cray can program in binary, then any REAL programmer can.

Re:I bet the format turns out to be...

[biobogonics]

When you consider the radical changes that have taken place between the standards for 66, 77, 90, 95 and proposed for 2000, I bet the format turns out to be Fortran.

Re:I bet the format turns out to be...

[Directrix1]

They should just make a processor that can run dynamic languages like Python more efficiently.

Didn't we do this once before?

[Uzik2]

I recall a system based on USCD Pascal. You would
write an interpreter on your target hardware that
would run the pascal p-code. It was supposed to
solve all sorts of problems. Except it was slow.
Nobody would write anything for it, I guess
because they didn't like Pascal, or USCD didn't
fire anybodies imagination with the product.

I don't see why we need to go through this again.
If you need performance write it in assembler or
use nicely optimized C. If you don't then an
interpreted scripting language will usually
suffice. What's the benefit to yet another
layer of abstraction?

Re:Didn't we do this once before?

[monadicIO]

And we'll probably be doing the same stuff for ages to come, if companies are to keep making money by reinventing the wheel. I don't see *popular* programming languages/intermediate formats/runtime environments having undergone any particularly significant change in quite a few years now. I don't see what .NET (no MS bashing intended here) with all its runtime/intermediate format/etc.. has done that is substantially different than what has existed before. (AND XML crap doesn't count at all as any kind of progress, IMHO).

Re:Didn't we do this once before?

[metalix]

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

Re:Didn't we do this once before?

[Uzik2]

I think you've got that one right! I thought VB was popular because it was simple and it had a nice programmers environment. It made programming look really simple. I made a lot of consulting fees fixing people's really bad VB code too. I'm not familiar with .NET but it just looked like more of the same. Is there a good development environment for linux? I thought I saw what might be one on sourceforge but it didn't look finished.

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

Re:Didn't we do this once before?

[angel'o'sphere]

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

Re:Didn't we do this once before?

[voodoo1man]

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.

Re:Didn't we do this once before?

[Valar]

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.

Re:Didn't we do this once before?

[droleary]

Sure, as long as your class looks just like a C# one.

Exactly right. This is a "lowest common denominator" issue, and most interesting problems have interesting solutions that aren't part of the LCD. We don't need a lot of new syntax changes to get the same old semantics. We need better abstraction frameworks in place so that we can more easily develop programs that solve problems that are encountered these days. I think .NET is doomed to fail because it's just another layer over the same-ol-same-ol, not a useful abstraction layer that adds new features.

Re:Didn't we do this once before?

[dmccunney]

I recall the USCD P-system, too. It was a nice idea. It might have been better received if the original implementation hadn't been on an Apple II. The concept requires reasonable horesepower to work effectively. It got ported to the original IBM PC as well, where it battled MS-DOS and CP/M-86 for market supremacy. Once again, it was on a platform that didn't have enough horsepower.

The P-system on a 386 might have been very interesting, but it had already been marginalized to a niche product.

We've seen it elsewhere besides UCSD Pascal: Pascal designer Nicholas Wirth's Oberon language is a programming language and operating environment. For that matter, so is Smalltalk.

What's the benefit to another layer of abstraction? Offhand, network computing in hererogenous environments. Assembler is machine specific. C doesn't always optimize nicely across architectures: you are at the mercy of what the particular compilers support. (Some of the guidelines aimed at Mozilla developers wax eloquent about this, and what rules of thumb you need to follow to write truly portable code.)

Hardware is getting fast enough that another layer of abstraction might just be a win, if it could allow the programmer to concentrate on the task and not worry about what would atually _run_ the code.

We'll see.

Re:Didn't we do this once before?

[joto]

I believe CLR is supposed to be portable like Java, but functions are compiled to machine level code upon their first call.

Actually, that would be exactly like java. There are very few JVM implementations that doesn't do JIT these days... (At least that people actually use).

Re:Didn't we do this once before?

[cakoose]

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.

Re:Didn't we do this once before?

[DrSkwid]

> Is there a good development environment for linux?

er, yes : awk sed grep sort join find

Re:Didn't we do this once before?

[DrSkwid]

Welcome to DLL hell writ large

no you're applications can have dependencies *across the network*.

Thought MFC40.dll was bad?

You aint seen nothin' yet.

Re:Didn't we do this once before?

[eyeye]

Theres quite a few to keep an eye on now, java,.NET,Parrot and more..
What we need is another IL that all the other ILs bytcode can be compiled to!

Re:Didn't we do this once before?

[NickFitz]

You might use assembler instead of C

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

How do you optimize assember?

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.

Assembler loses all higher level abstractions... In assembler I have nothing

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

Re:Didn't we do this once before?

[howard_coward]

The real reason to have an interpretive intermediate language is to sanitize code. It seems to me that the perfect IL is C... expresive, concise etc. And you can compile it too!

Re:Didn't we do this once before?

[Slash.ter]

Cross language inheritance is nothing unique. Jython has it. Jython and C# came about at roughly the same time.

As other posters suggest, problems start when you realize that Java has single inheritance and Python has multiple. The same problem occurs when bridging C# and Python.

I guess everything looks better when it comes from M$ PR department.

Re:Didn't we do this once before?

[BRSQUIRRL]

There really isn't any such thing as a "C# class"...there is a CLR class that just happened to be compiled from C# code. By the same token, there were never "VB6 classes"...they were COM components that implemented an automatically generated COM interface of the same name.

All throughout this article's thread, I see people saying C# when they mean the .NET CLR and vice versa. This makes me think that a lot of people still really don't know how .NET works...and Microsoft is largely to blame for that, I'll grant you.

You can use a CLR class that was written in any .NET language in any other .NET language. True, the .NET CLR itself doesn't support some of the things that you mentioned like multiple implementation (i.e. more than just the interface) inheritance, multimethods (which I'll have to confess that I don't even know what those are), etc. If you find yourself needing things like that to develop something, then you will just have to go with something else like staight C++.

Re:Didn't we do this once before?

[VertigoAce]

It's also worth noting that he CLR can do a bit more than straight C# is capable of. The one example that comes to mind deals with accessibility (public, protected, private). C++.net lets you declare something as "private protected", which means it can't be used outside of the current assembly, and it can only be used by derived classes within the assembly. The other five access specifiers exist in C#. In general I'd agree that VB.net and C# are basically the same language (I've only seen one thing that VB can do that C# can't). The only real reason for both to exist right now is that some people prefer programming in VB and others prefer C-like languages.

People here seem to want an impossible balance. You can create a LCD of languages to support interoperability. The interfaces between languages will have to be more limited than what can be done internally. In other words, you'd be able to use more complicated features within your program, but not expose them in your interface (this is basically what C++.net does). If you also make the demand that every feature of the language is capable of being used externally, you're basically going to require that every langauge support the exact same set of features.

Re:Didn't we do this once before?

[voodoo1man]

There really isn't any such thing as a "C# class"...there is a CLR class that just happened to be compiled from C# code.

From my (admittedly far from complete) understanding of the CLR, it seems that most features of CLR classes are motivated primarily by C# implementation.

Re:Didn't we do this once before?

[voodoo1man]

This is exactly the issue here. Despite what Microsoft says about interoperability of languages at the class level, interfaces between them will still have to be built up. To give .NET credit, this is a step up over ye olde Foreign Function Interface (although not in terms of performance). The big abstraction benefit one would probably get is with callbacks (although with the languages currently implemented on top of .NET I think it's still too early to tell).

Re:Didn't we do this once before?

[Uzik2]

Sanitize? What do you mean?

The reason I saw for having interpreted code
was so when you had errors it could stop, tell
you you had an error, where the error was, etc.

Re:Didn't we do this once before?

[Uzik2]

cat this | sed "1,$s/what I meant/not what I meant/g"

I use those. VB has the edit/compile/debug cycle
all in one interface. vi + gcc + gdb all in one.

Re:Didn't we do this once before?

[Uzik2]

Algorithmic complexity? Ok, I'll bite.
I'm willing to learn...

Re:Didn't we do this once before?

[Uzik2]

I can see network computing in heterogeneous environments being a reason for it, but practically I don't think it works. The only place you want that is in a beowulf cluster (supercomputer using many machines as nodes). Any place else it's just a virus waiting to happen. In a beowulf cluster you'd really want a non heterogeneous environment to make maintenance easier and because you could buy parts cheaper through economy of scales.

Perhaps what you meant was this would be
a good virtual operating system not a
virtual machine. Since most of what makes
porting hard is the environment having a
single environment would be more beneficial
than having a single assembly code.

People are too fractious to make it work in
practice I think though.

Re:Didn't we do this once before?

[Uzik2]

It would be interesting to see if:

A.optimizing at the assembler level (by the cpu)
+
B. optimizing at the pcode level
+
C. optimizing at the language level (by the compiler)
+
D. optimizing at the operating system level

would be better than:

A.optimizing at the assembler level (by the cpu)
+
C. optimizing at the language level (by the compiler)
+
D. optimizing at the operating system level

My guess is the higher the level the optimization
is done at the better, but having many levels
of optimization may not give optimal performance.

Re:Didn't we do this once before?

[howard_coward]

"To sanitize code": To render code impotent; To keep bad boys from diddling the system;

Re:Didn't we do this once before?

[JamesOfTheDesert]

Of course there are no performance comparisons out there vs Java, because part of the EULA is that you will not publish any. :

The EULA for what? The ISO/ECMA standard? Or a particular implementation, such as from Microsoft, or from the Mono project?

Anyone is free to implement the standard, and do whatever comparisons they like against it.

Unlike Java(tm), the CLR is an actual standard.

Re:Didn't we do this once before?

[ceswiedler]

Are you free to benchmark the single existing complete implementation of the CLR?

Were you free to benchmark the initial complete implementation of the JVM?

Did you know that you are not allowed to use Visual Studio to develop a word processor? Nor are you allowed to use FrontPage or InterDev to create web pages which criticise Microsoft.

I'll take Sun's 'free' over Microsoft's 'free' in this case.

Re:Didn't we do this once before?

[tlahoda]

Ever tried using a text editor and a console with console driven compilers and debuggers? In unix that's all you really need. If you do this within an xwindows session you can turn your entire desktop into your ide. Try it, you'll get more done.

Re:Didn't we do this once before?

[TheSunborn]

It is a problem however that you are not allowed to distribute java widtout including your own software written in java.

Re:Didn't we do this once before?

[angel'o'sphere]

You are offtopic.
You can not use the hand optimzed assembly (or assembler) you have crafted on your Amiga and let it run on a 486er.
Neither would it run on a Power PC, nor on a StrongARM.
You can not even use the same optimization approach over such platform differences.
I know that writing assembelr code is *fun*. I've written my self about one millin lines assembler code. And I've seen enough assembler code where 15 lines of C (written by me) where a magnitude or more times faster than the original assembler code. (E.G. a mini flight simulator on a MAC where the coder WANTED to bypass QuickDraw and wrote a Bresenham line draw allgorithm, accessing the memory byte wise. I rewrote that routine and accessed the memory in byte, word and double word, according to the amount of bits to flip in that word, and did not store it back after every pixel but only when the word was no longer needed. That was 30 times faster IIRC than the original assembler code)

Back on topic: On assembler code level there is nothing left what an our day optimzier can optimize further. It is allready as good optimzed as we can in our days. Either by the high levle compiler, which did best as it could on an RTL language, or by a human who wrote assembler directly.
Thats exactly the point. By having an intermediate language, which is not RTL, but higher level, optimizations on that higher level are doable. After those optimizations it gets compiled or JIT compiled to assembly anyway.
angel'o'sphere

Re:Didn't we do this once before?

[JamesOfTheDesert]

Did you know that you are not allowed to use Visual Studio to develop a word processor? Nor are you allowed to use FrontPage or InterDev to create web pages which criticise Microsoft.

Do you have references for these claims, or is it simply FUD?

Re:Didn't we do this once before?

[Uzik2]

Yeah, I've used vi/gcc/gdb to edit, compile, and debug. I even opened one session for each so I could easily do so. The integrated ide is designed to do this better and the user interface for gdb is cryptic and clunky at best.

A friend and I once had a friendly rivalry going
over vi. We would try to find the least number of
keystrokes needed for any function. He got to
be a real wiz at using history. He finally won
with the 'save and exit' trick. On sun boxes you
could save and exit by just hitting 'zz'. I told
him ':x' does the same, he answered 'you have to hit return after that though...' ;)

Re:Didn't we do this once before?

[Uzik2]

Ah. Well, I would guess interpreters weren't
designed with that in mind, but it is a nice
added benefit isn't it! :)

Re:Didn't we do this once before?

[chicogeek]

What do you mean by "dependencies *across the network*"? Are you referring to HREF application that rely on the Fusion loader? If so, what is your point? Is it that loading assemblies across a 100 Mb network is bad? Of course unless the version changes, they're only downloaded once. And where is the parallel between .NET and MFC40.dll? There were a number of things that were bad about MFC40, esp. when they added new entry points but failed to change the version #. But I'm curious what specifically *your* issue with it is.

Re:Didn't we do this once before?

[spongman]

rewrote that routine and accessed the memory in byte, word and double word, according to the amount of bits to flip in that word, and did not store it back after every pixel but only when the word was no longer needed

Yeah, useful for the horizontal case, but you could easily write that algorithm in C and have a decent compiler generate the equivalent (or probably better) code.

The real question is whether or not it's worth going to the effort when L1 cache access is almost as fast as a register.

Re:Didn't we do this once before?

[angel'o'sphere]

Well, if you would look at what you have quoted ... your argument is exactly what I said :-) LOL

angel'o'sphere

Article text

[kiwipeso]

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.

Re:Next try?

[gantrep]

Javagrande.org

What's the point?

[Sheetrock]

We've already established that moderate proficiency in a high-level language with a good optimizing compiler is worth far more than mastery of assembly in today's environment, what with the size and scope of most programming tasks nowadays. Creating an intermediate language seems to couple the worst inefficiencies of high-level programming and assembly micromanagement: something 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.

What's wrong with making a good compiler that writes directly to machine code? I would think Cray and IBM would be even more inclined to do so, given their control over the hardware their software will run on.

Re:What's the point?

[miu]

I think they are hoping that creating intermediate targets will make optimization and scaling easier. This is similar to the approach taken by gcc. The core compiler team can focus on creating a correct and effecient intermediate representation and the team porting to a new architecture focuses on taking the intermediate representation and creating correct and effecient assembly for that target.

Re:What's the point?

[basking2]

This is a good question to ask.

So, one of the ideas behind C# was to make an intermediate laguage (MS-Java-byte-code, if you will) which could be quickly compiled for the CPU in question. Stick a system call envrionment and garbage collector around it and you have [roughly] what C# is. One of the nice things about Java was that it was for no specific machine... it was very very simple at the instruction level, but making native code from that can be a pain.

Now, from the looks of the posted article some folks now want an intermediate laguage that can represent concepts like instruction vectorization and maybe SMP (hypter threading) and perhaps some other more complicated constructs that Java's machine code just doesn't talk about.

The end result is that you would have very fast machine code for the number-crunching loops in the code and portability. The compile time would be fairly quick and the optimization for the local CPU would be "smart" and fast if you marked up what where vectorizable instructions.

Why C# falls short, I can't say. I've only looked at the Java machine, never at how C# represets a program.

Hope this is helpful!

Re:What's the point?

[Tim C]

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.

Re:What's the point?

[plastik55]

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.

Re:What's the point?

[iabervon]

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.

Re:What's the point?

[tomstdenis]

" it's anything but slow"

It's also a memory hog! ;-)

Kiddin. Whatever I code in C. I let the compiler sort out what platform it runs on. [hint: I write portable C code so it doesn't matter]

Tom

Re:What's the point?

[btakita]

So, one of the ideas behind C# was to make an intermediate laguage (MS-Java-byte-code, if you will) which could be quickly compiled for the CPU in question. Stick a system call envrionment and garbage collector around it and you have [roughly] what C# is.

Another Java programmer, who has almost no experience with .NET, yet thinks he has enough "understanding" of .NET to put it into a nutshell. However, you're not as bad as most people.

Why C# falls short, I can't say.

Could it be that there is less than a snowflake's chance on the Sun that Sun Microsystems would suggest .NET over Java? It's corporate politics!! If Microsoft were trying this, they would be pushing .NET instead of Java.

Anyways, why are there a bunch of Java programmers, ignorant of .NET architecture and capabilities, who are so intent on slandering .NET? If people criticize something, shouldn't they at least understand that thing first?

I've only looked at the Java machine, never at how C# represets a program.

At least you admit you have no experience with .NET.

Re:What's the point?

[Tim C]

Please, enlighten us. I'm not trolling, incidently - I'm a Java programmer professionally, although I admit that I've not really looked too deeply into Java's bytecode, but I'm training myself in C# and .NET - I have a genuine interest.

Anyways, why are there a bunch of Java programmers, ignorant of .NET architecture and capabilities, who are so intent on slandering .NET? If people criticize something, shouldn't they at least understand that thing first?

Same reason you get C/C++/Perl programmers slandering Java, and Linux zealots slandering Windows, Windows zealots slandering Linux, vi users slandering emacs, etc, ad nauseum - people around here have a tendency to either hate what they don't know, or try it once, hate it, and never touch it again, remaining ignorant of how it has improved since.

Re:What's the point?

[HiThere]

I will consider "fair treatment" for NET once I'm convinced that it isn't tied by patents or copyrights or other legal restrictions to the implementations that MS chooses to allow.

OTOH, I'm dubious of Java for similar reasons. But Sun is in less of a position to be abusive.

Re:What's the point?

[grotgrot]

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

Because that doesn't give you best performance. Machine code represents an exact processor implementation. Tradeoffs have to be made with backwards compatibility (eg Redhat is compiled for Pentium), expected cache sizes (optimising size vs performance), processor specifcs (Itanium has 4 instructions per bundle, Sparc has one instruction after branch) etc.

While it is true that you could compile for an exact machine, it is a horrible way of trying to ship stuff to other people, and it does require recompilation if anything changes. (The former is why Redhat pretty much picks base Pentium - if they didn't they would need 5 or so variants of each package just in the Intel/AMD space. Granted they do supply a few variants of some packages, but not everything, and Gentoo people can confirm that doing everything does help).

Using IL lets the system optimise for the exact system you are running at the point of invocation. It can even make choices not available at compile time. For example if memory is under pressure it can optimise for space rather than performance.

It also allows for way more aggressive optimisation based on what the program actually does. While whole program optimisation is becoming available now (generally implemented by considering all source as one unit at link time), that still doesn't address libraries. At runtime bits of the standard libraries (eg UI, networking) can be more optimally integrated the running program.

Machine code also holds back improvements. For example they could have made an x86 processor with double the number of registers years ago. If programs were using IL, a small change in the OS kernel and suddenly everything is running faster.

Needless to say, using IL aggresively is not new. To see it taken to the logical conclusion, look into the AS/400 (or whatever letter of the alphabet IBM calls it this week). I highly recommend Inside the AS/400 by Frank Soltis.

Re:What's the point?

[angel'o'sphere]

Ah, come on, that is anything but not insightfull ...
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++ ... and so on for Smalltalk, Python, LISP ...
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 ... 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.
angel'o'sphere

Re:What's the point?

[basking2]

LOL!! Whoops, I mixed up .NET and C#. Sorry about that. Yes, I am a Java programmer more so than a C# programmer. No, I do not have no experience with .NET.

I will say that I'm a little annoyed that you chose to fly off the handle like you did. So, rather than get into a shouting match with you, here is a paper for you and the folks here to check out on the JVM and CLR. Note that they are both largly stack machines but the CLR from MS made some design improvements. Please also note (if you are familiar with large scale NUMA-type number chuggers) that neither machine language is built very well to JIT down to that architechuture. If you aren't familiar with Non-Uniform Memory Access machines, google around. They are very cool and you don't have to know alot about them to realize the a stack machine isn't the best model for tight-looped matrix math.

Again, I hope this is helpful and please chill for a few minutes before you blast me. :-P

Re:What's the point?

[neurosis101]

Itanium is 5 instructions per bundle. 1 branch instruction, 4 aritmetic/logic ops.

SPARC is not any instruction after branch, its only non data dependent ops, as well as non synthetic operations.

/pedantic =)

Re:What's the point?

[Lazy Jones]

Because a well-designed intermediate language will help optimization

All good compilers already use well-designed intermediate languages. A general intermediate language that aims to be equally suitable for many high level languages will most likely be inferior to the best intermediate language for a particular high level language.

The other benefits of using an IL are manifold. New languages can be implemented without having to write a compiler for each platform.

Great. Just what we need - another of those braindead technological "advances" like human-readable data interchange formats that makes life easier for a few developers (simpler, cheaper compiler development) and harder for millions of users (worse performance). Frankly, the only advantage for the rest of us I can think of would be the higher probability of the resulting tools being mostly bug-free.

Re:What's the point?

[NoCleverName]

I would envision something along the lines of a PostScript-level language as an intermediate ... something at a fairly high semantic level with dispatchable computation elements. You've got to be able to describe computations large enough to be worthwhile sending out to a bunch of fast processors while freeing the programmer of having to manage all this. Thus, a new high level language for programmers and a new intermediate one for fabrics of machines. Nobody says the intermediate can't be compiled deeper.

Re:What's the point?

[Mr Smidge]

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

What's wrong with encouraging good clean portable code, using good clean portable libraries?

Re:What's the point?

[Mike McTernan]

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.

Re:What's the point?

[n3k5]

Moderators beware! (I have mod points myself at the moment, but if I mod this down without commenting, I guess it will be at 5 in no time again.) Apparently several people find this post insightful; however, the author actually didn't understand the intermediate language concept at all.

What the article describes is absolutely not "akin to writing machine code directly for a VM". To the contrary, the IL code would be generated automatically, thus eliminating the need of assembly micromanagement. To make it fast, effort would have to go into a compiler that does good automatic optimizations, as well as into writing efficient code in a higher level language. The idea is that you have to do this only for one well-known platform, not for every piece of iron your code runs on. Optimization is made easier, this also the "inefficiencies of high-level programming" are reduced.

Maybe the original poster didn't get that this new IL wouldn't run on top of a Java VNM, nor below it, but rather do a similar job, but in a way much better suited for big iron and big tasks ("petascale systems").

Re:What's the point?

[AKAImBatman]

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.

Re:What's the point?

[btakita]

Theres Mono or dotGNU, which are OS implementations of .NET. .NET 1.x and c# are ISO standards, so anybody can roll their own implementation.

I dont know about OS implementations of Java.

Re:What's the point?

[btakita]

I'm sorry. I didn't realize I was being a dick until I read my post after your reply.

I didn't have much to go on. You refered to .NET as C#, then made some generalizations, and I stopped listening after that.

Your generalizations are not inaccurate, but coarsly grained, which is fine because the topic is about high performance computing.

Thank you for the information and for the reply.

Re:What's the point?

[finkployd]

In the large enterprise setting where I work (100000 or so very active users) we have pretty much ruled out java for anything production that needs high availability. Java is nice for applets or client applications, but for server side stuff it just makes no sense at all for us (unless we decide we want to throw TONS of hardware at it).

Java is simply is not as fast as a compiled language (specifically C, which the majority of our stuff is done in). More importantly than that though, it does not scale nearly as well.

Finkployd

Re:What's the point?

[angel'o'sphere]

Come on, get a clue.
Writing a VM is a first year CS subject. Especially if you have all the specs and likely a reference implementation. Writing a compiler is TOUGH.
Why do you think code running on a good Java VM is FASTER than the equivalent code written in C/C++? Well, I asume you don't even know that this is the case.
If we had a standard VM every hardware vendor would be "forced" to supply a VM with his processor.
You forget: a VM is not only the processor abstraction but also the OS abstraction. So basicly every OS vendor or processor vendor would WANT to have a VM for his environment.

angel'o'sphere

Re:What's the point?

[angel'o'sphere]

google for JOS

angel'o'sphere

Re:What's the point?

[fm6]

Creating an intermediate language seems to couple the worst inefficiencies of high-level programming and assembly micromanagement

You're assuming that the IL is something people would actually program in. My reading of the article says that IL is just another kind of bytecode, like those in current Java class files, but designed specifically for HPC.

The great white hope of the Java community is a VM implementation that's as fast as simple native code -- if not faster. That might seem like a Quixotic goal, but the VM wonks at Sun have always insisted that it's possible. So far, they haven't deliverd, but maybe they could if their VM was better designed for HPC.

Re:What's the point?

[Kent Recal]

100.000 simultanous users seems a lot (depending on your application) but I doubt java comes with a builtin bottleneck that you couldn't work around by just rewriting only the code causing the bottleneck in native C or even asm.

What were you trying to do that would've required to throw "lots of hardware" at to make it work?
Just curious because that "server side stuff" you mention is where java usually shines, so what funky things were you doing?

Re:What's the point?

[elmegil]

That should be obvious. C# is a Microsoft product. You ain't gonna see Sun adopting it.

Re:What's the point?

[finkployd]

In one case, it was digitally signing signing XML. Java absolutly sucks as anything involving cryptography in my experience. One of the developers was able to get a decent speed boost using Mozilla's NSS library instead.

Another problem is servlet containers (like Tomcat). Frankly they just suck under any kind of heavy load.

Once you start talking about striping out the pieces that perform poorly in Java, it just makes more sense (in our situation anyway) to just write the whole thing in in C or another compiled language.

Finkployd

Re:What's the point?

[Kent Recal]

Probably you shouldn't judge java only by its reference implementation of a servlet engine (tomcat). There are much faster beasts available that also do away with the load problems your tomcat might be expiriencing.

And expensive crypto-computation should ofcourse be done in native code but that doesn't imply that your whole app must be native. Maybe a bit more evaluation could have saved you a lot of time.

Re:What's the point?

[edp]

"... worth far more than mastery of assembly in today's environment, what with the size and scope of most programming tasks nowadays."

If you take away most of the billions of dollars spent on programming tasks nowadays, you are left with only a few billions for which mastery of assembly might be useful. That's the point.

For most programming tasks, compilers do fine, or they do okay and it isn't worth expending the effort to do better. But if you are building an expensive system with many processors, you can save money by hiring a high-performance assembly-language master to do what the compilers cannot. And if you are a company that sells high-performance computers, you absolutely need engineers with those skills to produce optimized code.

There are some tasks compilers still aren't good at. An expert can write an assembly-language FFT that's faster than the code produced by compilers, even those specialized for high-performance parallel applications. If the percentage speed improvement in the application multiplied by the cost of the processor multiplied by the number of processors you need is lower than the expert's cost, then you hire the expert.

Re:What's the point?

[S.Lemmon]

This is always said in regard to the patent issue, but does being an "ISO standard" automatically mean there's no patent issues? Unless it's explicitly required to be unencumbered for standardization, I don't see why it's relevant to the patent issue.

In any case, Microsoft has no reason to crack down now as it would just hurt NET's adoption. However, they could just be waiting for enough people to depend on it before playing their patent card.

I've seen some NET proponents fall back on the rather shaky belief that "Microsoft doesn't have a history of abusing patents that way."

Relying on the "goodness" of any company in this way is a bit foolish - especially so after the recent FAT32 flack. Many a company has been burned by thinking they could trust Microsoft.

Re:What's the point?

[gregfortune]

hmmmm, the only one I've even *heard* of is JBoss and I wasn't even sure what it does ;o) Personally, if I've got a choice between a Java app and one in C or C++, I'll use the C or C++ app everytime. Jedit is a kick butt editor with some awesome features (code folding is the one I *really* want), but I use Nedit instead primarily because it starts fast and I'm opening source files of a konsole hundreds of times each day.

Note for those of you who saw "konsole".... Yes, KDE is slower than some WMs I could pick and that appears to be a contridiction, but I never restart it and once it is started, it clips right along given plenty of RAM.

Re:What's the point?

[vt0asta]

You java fanboys are the best.

Blockquoteth thee

work around by just rewriting only the code causing the bottleneck in native C or even asm.

I couldn't have said it better myself. Get over it. Sometimes, Java isn't cost effective, and sometimes Java isn't even appropriate server-side or client-side (hint: java is not fault tolerant, way too much leeway with the GC and byte code ordering).

Most people's problem with Java is the fact that it was initially paraded and promised as having a) very low memory foot print, b) very low binary/byte code size (for very fast network download), and c) portability.

a) Has yet to be realized.
b) Was for a bit, and now it's insane.
c) Is no more portable than C source code.

Not only that, I even remember the knuckleheads who wrote the language leaving Sun to go off and make snazzy new Java applications under a company called JavaSoft. Oops.

Sun was also going to make specialized Java byte code processors picoJava, microJava, ultraJava. Vaporware. Vaporware. Vaporware.

So Java can finally do server web-based applications as fast as Perl or C, and now it's suppose to be hailed as the programming language messiah? However, years later it's found it's still not good enough for some applications, that the big dogs have to make an intermediate programing language.

Please understand, Java != (good for everything).

Re:What's the point?

[AKAImBatman]

Have you tried any of those? You might be pleasantly surprised.

DataDino is a database management tool similar to Toad. It slices, it dices, it edits data and tables on the fly!

JGoodies produces an awesome tool for finding dead files that are eating up hard drive space.

Azureas is a BitTorrent client that works far better than even the Shadow client. (Anyone remember how Furi rocked the house before LimeWire muscled in?)

JBoss is an example of a J2EE server. If you don't know what that is, it's probably because you're not a web developer. J2EE technologies are running the high end web applications of today, both the visible and invisible ones.

Think Free is a great little Microsoft Office replacement in Java. (Sadly they haven't seem to have changed much since their initial release, but it's still good stuff.)

So on and so forth. Of course, if you want a little fun, go check out a few Java games like Wurm Online.

Re:What's the point?

[AKAImBatman]

I'm sorry, but this is pathetic.

Number 1 priority is to get yourself a decent cryto lib. Bouncy Castle makes a very nice free one, but if it doesn't meet your performance needs you may want to look for a commercial one from the likes of RSA. And in case you're wondering, several of my associates have used cryptography as an example of how fast Java can be.

A straightforward implementation of a Java crypto lib usually outperforms a similar C implementation thanks to the VM optimizing the code behind the scenes. Even the most optimized C code only outperforms the Java versions by one or two percent. The problem with most Sun libs is that they're built for absolute correctness, not speed. Besides, it's not like the JVM comes with any *useful* crypto libs in the first place.

Number 2 is that you seem to have spent all of 5 minutes shopping for a servlet container. Tomcat is known to be slow. It's supposed to be slow. It's a reference implementation for Christ's sake. Orion Server (the basis for Oracle AS) is a great performer, plus is very cheap. Resin is great if you don't need an EJB container. Hell, even Weblogic does a pretty good job at performance.

Memory is really your biggest enemy. The amount of crap that you sometimes need to keep "in session" for a client is absolutely astounding. Still, this is not a Java only problem, and there are multitudes of solutions (such as using a database table as a cache and trading page render time for memory usage).

Re:What's the point?

[gregfortune]

DataDino - I'm using a data model compiler I developed so I don't write as much SQL anymore. When I do, it's either through the command line mysql client, the C++/Qt MySQLCC editor from MySQL (looks a lot like DataDino) or my own custom reporting app.

JGoodies - 5 years ago I used a VB app a buddy wrote for this ;o) Now, the command line tool du does a great job.

Azureas - This probably wouldn't be a bad Java app as you start it up and then leave it running. Ignoring RAM consumption, it probably performs pretty well. Too bad I don't use BitTorrent...

JBoss - Not a java web developer. Mostly custom client side apps written in Qt. Again, this one probably isn't affected by startup times as it probably runs as a daemon.

Think Free - lol, that's the only link I didn't click on and glance at before I replied earlier :) Pretty much anything has got to start faster than OO and that's what I'm suffering with right now. Just crossing my fingers that KOffice will catch up. Guess I should try out Think Free as well.

Wurm Online - Ok, pretty sure I hate you now. Just what I need... Another pretty cool looking game I can play ;o) And as long as it starts up in under 5 minutes, I could care less.

Re:What's the point?

[h8sg8s]

Most of you are missing the core of the DARPA HPCS program goals. These are *big* computing systems with possibly thousands of CPUs and many TB of RAM. Look at this metalanguage as a tool for compilers to target where paths (routes) and resources can be configured for a specific task or goal in mind. It's really a hardware or system-level metalanguage. Based on this, I think it's an idea whose time has long since come.

Re:What's the point?

[AKAImBatman]

DataDino - I'm using a data model compiler I developed so I don't write as much SQL anymore. When I do, it's either through the command line mysql client, the C++/Qt MySQLCC editor from MySQL (looks a lot like DataDino) or my own custom reporting app.

Ah, but DataDino provides access to multiple database vendors (read: MySQL, Oracle, SQL Server, etc.) on Windows, Linux, OS X, Solaris, HP, and many other OSes! Not to mention that it's about $450 cheaper. $495 cheaper (i.e. free) if you only need to do simple tasks. :-)

Granted, it doesn't (yet) have some database specific features such as server settings, but those settings are often managed by the DB sysadmin with command line tools anyway.

JGoodies - 5 years ago I used a VB app a buddy wrote for this ;o) Now, the command line tool du does a great job.

In my experience, Unix machines don't suffer from the "lost file syndrome" as badly as Windows machines. This probably has a lot to do with files being forcefully kept in home directories. Usually when a Unix machine is a mess, everyone knows it's a mess but is too lazy to clean it up. :-)

As to a custom solution in VB, I'll bet it didn't have pie charts, graphs, "top 100" listings, and other great features that help find those lost ISOs, installers, temp files, etc. Oh, and did I mention that it's free? :-)

Azureas - This probably wouldn't be a bad Java app as you start it up and then leave it running. Ignoring RAM consumption, it probably performs pretty well.

The Java startup time is really overrated. It actually takes the regular BitTorrent GUI longer to start than the Azureas GUI. I think it has something to do with its poor handling of large file hashes.

Too bad I don't use BitTorrent...

You use Linux and you don't use BitTorrent to download it?! String him up by his pinky toe!

Seriously, BitTorrent is WAY faster than trying to get ISOs from the primary download mirrors. Every download actually increases bandwidth to the BT network, so more downloaders == faster downloads.

Wurm Online - Ok, pretty sure I hate you now. Just what I need... Another pretty cool looking game I can play ;o) And as long as it starts up in under 5 minutes, I could care less.

BWHAHAHAHA!!! You've fallen for my evil plan! Too bad you're on Linux, or you'd fall for my 4K game contest entry called WarGames. Sadly, I was too lazy and too constrained by space to add support for Linux. The problem is that Full Screen mode is not currently supported on Linux, and I didn't bother to check that in my code. A simple fix is to comment out the method to set the resolution in the "main()" method and recompile.

BTW, I forgot to mention anything about SmartCVS. Thomas Singer would wring my neck if he found out. Actually, I should wring my own neck as it's really a great product. I usually use the built in IDE functionality for CVS checkins, but for tree maintenance, tracking changes, and just generally working with the whole tree at a high level, I always drop to SmartCVS. If you're still using anything other than TortoiseCVS (sadly only available on Windows), you NEED to do yourself a favor and check out SmartCVS.

Re:What's the point?

[btakita]

Why didn't they play the "patent card" with Win32? They could have raked in the dough by charging every application developer a licensing fee.
Because it has anti-trust all over it and would hurt Microsoft more than help it.. The same thing applies to .NET.

We will see how Ximian turns out with Mono. You think they will get screwed, I bet they wont for these reasons...
* It would be a marketing nightmare
* This would kill adoption of .NET on Linux (Yes, Linux is here to stay)
* It will cause an exodus to Java

A licensing fee, or blocking competitor's products, is small potatoes compared to .NET ubiquity.

Re:What's the point?

[whereiswaldo]

Why didn't they play the "patent card" with Win32? They could have raked in the dough by charging every application developer a licensing fee.
Because it has anti-trust all over it and would hurt Microsoft more than help it.. The same thing applies to .NET.

That may be so that antitrust would come into play, but I really doubt that is the reason Microsoft hasn't charged app developers licensing fees for Win32.
The real value of an operating system is the applications that run on it. Microsoft wants everybody to be writing applications for MS Windows, and not for other operating systems. It is in their best interest not to charge licensing fees to allow people to write on their OS.

On the other hand, it is not in their best interest to have a lot of people writing applications for Linux and other operating systems (since that adds value to those operating systems). For this reason, I would not be surprised if Microsoft tried to hinder development on other platforms, however that may be accomplished. The bottom line really is, it's up to them what they want to happen with .NET, not you.

Re:What's the point?

[Bob Uhl]

Is it actually possible to slander or libel Java? After all, the common key to both is that a statement be both negative and false. I cannot think of any negative phrase which isn't true of Java...

Re:What's the point?

[Unordained]

yeah, but see, we're right about linux and c++. and islam. or ... somesuch.

as a c++ programmer, i've found that talking about java is always about a dozen issues at once, regardless of how much you know about the language (and history, etc.) it's not just about the language itself, it's about standards, supporting libraries, performance, interaction with the OS, etc. eventually, you always have to throw in a few other languages for comparison (and to make a point) -- like talking about perl and the many available libraries ... and how you can't find anything, but also aren't forced into a particular way of doing things. it's almost never fair, and besides -- we all want our languages for different reasons.

always about trade-offs. by the dozen. maybe we should select religions as if they were a toolset. that could be amusing.

Re:What's the point?

[gregfortune]

Granted, it doesn't (yet) have some database specific features such as server settings, but those settings are often managed by the DB sysadmin with command line tools anyway.

Yep, that's me :) As an independant consultant doing everything from project management to programming to tech support, I end up doing pretty much everything and most of it remotely through ssh.

As to a custom solution in VB, I'll bet it didn't have pie charts, graphs, "top 100" listings, and other great features that help find those lost ISOs, installers, temp files, etc. Oh, and did I mention that it's free? :-)

Yes, all of those things... Is it as fast as du and find? Couple that with the fact that I really don't care about the graphs/etc and it's not something I'll probably ever bother with. Admining remote servers does something weird with the minds of people and prevents them from enjoying any nice GUI tool 'cause they're not real useful through ssh with X forwarding disabled ;o)

You use Linux and you don't use BitTorrent to download it?! String him up by his pinky toe!

Yep, no BitTorrent for me. Gentoo freak here. You use Linux and you need BitTorrent? Hand over your geek license now! :)

Wasn't able to get Wurm Online working... Looks like most of the people on Windows centric anyway, but I might post a message up on Monday and try to get it figured out.

As far as CVS goes, I'm command line. If I have to do a diff, I end up in kompare (very very sweet little program) and I've fired up Cervisia a couple times, but haven't really found it necessary. I don't do much tree maintence because I'm a pretty solitary developer, but for the times I have needed to look through changelogs, etc, the command line tools suffice. If times change and I actually get to hire employees (woot!), I'll have to hunt down a good tool like SmartCVS. If it's the only thing available, I'll run it even if it starts slow :) FYI, the screenshots make it look like a very nice program.

Back to the topic at hand, I agree that apps can be written poorly in general and a slow startup time in an app doesn't mean that all apps written in that language will be slow to startup, but my personal experience thus far is not very promising.

When I said I avoid Java apps when I have a choice, it's because when I look for a new editor/tool/etc and I compare a couple of apps, I tend to gravitate towards those apps that *feel* fast. I have yet to find a Java app that I *enjoy* running.

Re:What's the point?

[jeti]

In that case you can't work anymore with software
at all. No one can tell you that a technology,
platform or standard is free of patents or copyrights.

AFAIK for example JPEG has been taken back as an
ISO standard because patent claims have surfaced.

The only way to work at the moment is to close
your eyes and hope for the best.

Re:What's the point?

[btakita]

When is it really up to you and me? Outside forces always conspire to dictate what direction we move in. Whether its market forces, evil companies, or corporate fads, we don't have ultimate control over what and how we develop. This doesn't apply to software development as artistic expression, but if you want to get paid for your artistry, then we all are at the mercy of the people who have the money.

I like .NET because it is a well designed platform. If Microsoft gets stingy, then it may be worth it to move to a different platform. There are plenty to choose from and through web services, it is getting easier for different platforms to talk to each other.

Re:What's the point?

[S.Lemmon]

If you're developing for the Windows then I'd say sure - go with NET. Microsoft will welcome you.

However, if you think using NET on a non MS OS is a safe bet then think again. Without a solid guarantee that it will always be unencumbered and patent free, the open source community would be putting a noose around its neck and trusting Microsoft not to pull the lever.

It's not a trivial matter to just move years worth of code to a new language. You're of course free to take that risk if you choose, but didn't your parents warn you about taking candy from strangers?

Re:What's the point?

[MyFourthAccount]

We've already established that moderate proficiency in a high-level language with a good optimizing compiler is worth far more than mastery of assembly in today's environment, what with the size and scope of most programming tasks nowadays

Hehe, yeah, ya'll just keep shouting that, while I'm getting 6 figures a year and jobs to choose from, writing x86 assembler.

Seriously though, I'm no assembler zealot (I prefer C[++]), but it is amazing how inefficient some software is. And a little knowledge of how it translates to how the CPU processes it, could improve things a lot.

I remember reading that Torvalds would look at the assembler output of the compiler to see what it generated. I do that a lot too, and it really helps...

But anyways, don't get me wrong, I appreciate the need for higher-level programming languages and machine independent binaries.

Re:What's the point?

[jrumney]

Theres Mono or dotGNU ... I dont know about OS implementations of Java.

The usual MS fanboy response to Java articles. Go look up kaffe and gcj sometime. Or go look up the original JRE's Sun Community Source License even.

Re:What's the point?

[Haeleth]

Great. Just what we need - another of those braindead technological "advances" like human-readable data interchange formats that makes life easier for a few developers (simpler, cheaper compiler development) and harder for millions of users (worse performance).

I'm sorry? The compiler most people here probably use is GCC, which already uses a general-purpose IL to compile a range of very different high-level langauges. And indeed it doesn't perform as well as, say, Intel's C++-specific compiler. But I haven't seen any studies which suggest this is the fault of the IL alone; and its performance is good enough to have made Linux compiled with GCC a respectable choice for enterprise computing.

A universal standard IL would be unlikely to result in worse machine code than GCC produces, so millions of users would notice no difference whatsoever. And meanwhile it would make life easier for many developers. I really don't see a problem with this. So far as I can tell, what you're saying is "I don't think it will work, so you're idiots to even consider it".

Well, all I can say is that if everyone had that attitude, the major hardware platform today would still be the abacus.

Re:What's the point?

[throwaway18]

He points out that "it's a bit of a strawman to argue that startup time doesn't matter." and you respond with... a strawman argument!
None of your links are applications where the startup time time matters which actually support's the AC's point of view.

Re:What's the point?

[Haeleth]

Why do you think code running on a good Java VM is FASTER than the equivalent code written in C/C++? Well, I asume you don't even know that this is the case.

Please provide the evidence on which you are basing this bold claim, so that I too may be enlightened.

Re:What's the point?

[Lazy Jones]

The compiler most people here probably use is GCC, which already uses a general-purpose IL to compile a range of very different high-level langauges.

You've got a point there. However, GNU C and related compilers plugged a big hole (free compilers are badly needed), so I wouldn't consider the trade-off (cost of development vs. performance) a bad one.

What I'm saying is not that it won't in some cases be useful to opt for generality rather than optimization for a particular platform (esp. if it helps to develop new compilers that wouldn't otherwise have been possible), but that it would be wrong for major software vendors to abandon language-specific intermediate languages (which, IMHO, have shown to result in better performance) in favour of a general-purpose IL that is touted the "next big thing". I'm all for advances in compiler research (general IL are somewhat out of fashion already though), so I'd be glad if this helped produce better compilers, but my guess is that it'll result in reduced costs, fewer jobs and worse performance at a higher price for the end-user. It'd be a much saner thing to improve GCC until the approach can be shown to have advantages for the rest of us (over the existing commercial compilers by the same companies)...

Re:What's the point?

[EJB]

One of the most interesting things is dynamic (re-)optimization. Sun has experimented with this, and the Java HotSpot engine does some of it, although it is restricted by the java bytecode which is too explicit and low-level.

Dynamically re-compiling intermediary code depending on its actual use at the time can give (at least theoretically) some very good performance. It can also re-adjust to the environment, for example re-adjust the application to more CPU's being added to the pool.
An old-style compiler would have to compile the same high-level code many times to different assembly code to achieve the same result, which would make the resulting object code too large. A dynamic JIT compiler typically has a cache from which it evicts the least-frequently used pieces of compiled code.

Re:What's the point?

[groomed]

We've already established that moderate proficiency in a high-level language with a good optimizing compiler is worth far more than mastery of assembly in today's environment

Only if "today's environment" is composed of beige desktop boxes. When programming for embedded systems (say, a mobile phone), a proficient assembly programmer can make the difference between a product that never makes it to market and a product that succeeds wildly.

Deep skills allow companies to save $dollars on each unit shipped. With volume, this saves millions.

Re:What's the point?

[JoshRoss]

When is the last time Jesus has slid his ass down a chimney to give anyone presents? I vote for a religion with Santa Claus replacing Jesus.

Re:What's the point?

[finkployd]

While those are good points, one of the requirements for the software in question is that it is open source, and needs to involve only open source or at least free (like java) technologies. So I guess maybe my problem with java is that there are no decent free or open servlet containers, crypto libs, etc that can scale well and perform under a heavy load. Hence our preference for C.

I'm not trying to cut down Java, I have spent a long time working with it and I like it. But working in a huge enterprise setting was a big eye opener for me.

Finkployd

Re:What's the point?

[AKAImBatman]

While those are good points, one of the requirements for the software in question is that it is open source

That's a bit of an odd requirement, but a fair enough one I suppose. One thing you are going to need to keep in mind is that Open Source programs are usually not focused on raw speed (with a few minor exceptions where the problem domain requires it).

Bouncy Castle is only one example of free crypto libs. I've personally been more impressed by its ability to do just about anything vs. performance. Still, it has not resulted in any negative performance for my employer's web application. Which is a good thing, because whoever speced the original server machines was apparently of the "a PC can run your business!" thinking. Of course, he wasn't the only one I want to strangle, but that's beside the point.

Probably your best bet for an Open Source J2EE server would be JBoss. They've spent time creating their own high performance servlet container and have optimized the hell out of the EJB component. I personally don't find it as easy to deploy as Orion, but the source is there, and you can easily hire an army of JBoss consultants to help get you going (not my cup of tea, but managers like that stuff...).

One other thing you need to consider in an enterprise environment that many developers miss: If you're spending time hand optimizing code or troubleshooting server wide crashes caused by memory leaks or illegal memory access, you're wasting your employer's money. A decent developer costs between $85-$130K per year. Scaling your hardware just a little larger costs significantly less. It's a good thing to keep in mind when you consider the costs of hardware. :-)

Re:What's the point?

[Tim C]

I cannot think of any negative phrase which isn't true of Java...

How about, the design of the language makes it extremely easy to unintentionally write code that contains possible buffer overflow exploits? (In fact, all arrays, strings, etc are bounds checked at runtime, whehter you want it or not, making such exploitable code all-but impossible to write)

Yes; IHBT, IHL, IWHAND.

Re:What's the point?

[AKAImBatman]

Yep, no BitTorrent for me. Gentoo freak here. You use Linux and you need BitTorrent? Hand over your geek license now! :)

Actually, I only keep Linux around to do software compatibility testing. I prefer to work on FreeBSD or Sparc Solaris. Considering that I've been recompiling BSD ports and kernels since before Gentoo existed, I think my geek license is pretty safe. :-)

Wasn't able to get Wurm Online working... Looks like most of the people on Windows centric anyway, but I might post a message up on Monday and try to get it figured out.

Last I chatted with him, the developer was trying to keep it running on Windows, Mac OS X, and Linux. In fact, I just checked the JNLP file and the native Linux OpenGL libs are listed. Are you getting an error message after launching, or are you having difficulty with Webstart? Java Webstart is a great technology that allows applications to launch right off of a web page with maximum security enabled. Unfortunately, Linux doesn't do desktop integration very well at this point. Here's a quick guide to get you going:

1. Make sure you have Java 1.4 or higher installed (1.4.2+ is best at the moment).

2. Check in the directory you installed Java. There should be an installer called 'javaws'. This will extract the 'javaws' executable and supporting files.

3. Run 'javaws', go to 'File|Open' and paste the Webstart URL for Wurm into it.

The application should launch without difficulties.

Back to the topic at hand, I agree that apps can be written poorly in general and a slow startup time in an app doesn't mean that all apps written in that language will be slow to startup, but my personal experience thus far is not very promising.

I'd be curious about what experiences you've had. Most people tried a few unpolished Java apps years ago and since then have had a constant opinion of Java. The truth is that professional GUI developers have entered the Java development realm and have been steadily producing excellent Java software ever since. Still, it's been pretty slow as no one really wants to rewrite applications that already work. As a result, the best Java programs are in niches were no current C/C++ program exists. For example, many of the best P2P apps are Java based. Sometimes you'll even use Java software without even knowing it (such as Nikotel online phone software, NetZero dialer, a lot of the Red Storm games, etc.)

When I said I avoid Java apps when I have a choice, it's because when I look for a new editor/tool/etc and I compare a couple of apps, I tend to gravitate towards those apps that *feel* fast. I have yet to find a Java app that I *enjoy* running.

Well, keep your eyes open. Most of the Java apps today are in a different market than you've described yourself. That's changing as apps start pushing more and more into the consumer market. I wouldn't be surprised if in the near future a large chunk of your apps end up being Java. :-)

Re:What's the point?

[finkployd]

That's a bit of an odd requirement, but a fair enough one I suppose.

Cross institution, higher education application.

Bouncy Castle is only one example of free crypto libs. I've personally been more impressed by its ability to do just about anything vs. performance.

BouncyCastle does what we need it to do, but is still orders of magnitude slower than openssl or even NSS (which thankfully does have a JCE interface but unfortunatly does not do java keystores)

Probably your best bet for an Open Source J2EE server would be JBoss.

That, and NSS are probably the directions we are going in. what we are talking about here is not a j2ee application, but just a simple servlet to do federated authentication/authorization with SAML. Either way though, I've heard a lot of good about JBoss.

One other thing you need to consider in an enterprise environment that many developers miss: If you're spending time hand optimizing code or troubleshooting server wide crashes caused by memory leaks or illegal memory access, you're wasting your employer's money.

Not to launch into "marketing brag mode here", but my university has become exceedingly good at developing in house solutions in C and avoiding these problems. When none of the existing webmail packages would scale well enough for our environment, we wrote out own. Same thing with our portal framework. It always amuses us when companies try to sell us solutions without understanding how large we actually are. Microsoft wanted us to use Exchange for our email system, until we pointed out our size (100,000 users, generally 3-4 million emails a day). We do that with 6 nodes in a few SP clusters (AIX and Sendmail), while Microsoft used some 100 servers for a population 1/4 of our size. Our experience has long been that we can develop better in house solutions (generally using C) than we can buy for most infrastructure applications.

A decent developer costs between $85-$130K per year.

Not in higher ed :( I make about half that and I maintain that I am a decent developer.
However the benefits are nice: 24 vacation days a year, 75% tuition discount, freedom to play with some really cool tech, and job security, baby :)

Finkployd

Re:What's the point?

[Grizzlysmit]

We've already established that moderate proficiency in a high-level language with a good optimizing compiler is worth far more than mastery of assembly in today's environment, what with the size and scope of most programming tasks nowadays. Creating an intermediate language seems to couple the worst inefficiencies of high-level programming and assembly micromanagement: something 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.

What's wrong with making a good compiler that writes directly to machine code? I would think Cray and IBM would be even more inclined to do so, given their control over the hardware their software will run on.

So, one of the ideas behind C# was to make an intermediate laguage (MS-Java-byte-code, if you will) which could be quickly compiled for the CPU in question. Stick a system call envrionment and garbage collector around it and you have [roughly] what C# is. One of the nice things about Java was that it was for no specific machine... it was very very simple at the instruction level, but making native code from that can be a pain.

Now, from the looks of the posted article some folks now want an intermediate laguage that can represent concepts like instruction vectorization and maybe SMP (hypter threading) and perhaps some other more complicated constructs that Java's machine code just doesn't talk about.

The end result is that you would have very fast machine code for the number-crunching loops in the code and portability. The compile time would be fairly quick and the optimization for the local CPU would be "smart" and fast if you marked up what where vectorizable instructions.

Why C# falls short, I can't say. I've only looked at the Java machine, never at how C# represets a program.

Hope this is helpful!

Basically if you do this really low level there's no point, for it to be worth anything it would need, to be a sort of slightly higher level assembler, (i.e. like Perl 6's Parrot), basically you go fairly low level, but you still want to abstract away all the machine pacific stuff, and you should support some concepts traditionally thought of as the domain of high level languages, for instance: strings, arrays, hashes/assoc arrays, struct's, functions, and basic object support. This language, can then be supported two ways on all real world architecture's:

1. You have a runtime interpreter to run it directly.
2. You have a compiler that can convert it to the machine code of a given machine.

The main issues are: you have are:

• Making sure it can be converted fairly rapidly to machine code.
  To insure there's not too much penalty in running it in interpreted mode.
• Making sure it's a good intermediate target language for a compiler to convert to real machine code.
• Making sure it's a good target for an dynamic interpreted language like Perl, Python etc...

If I where them I'd be looking closely at Perl 6's Parrot, and gcc's intermediate machine independent form. I'd also look at allowing interpreted blocks, in the compiled case, so if because of dynamic features in the code a given chunk, cannot, be compiled to real machine code at compile time, you just include a call to the interpreter passing that chunk, of course, there are better ways you could have dynamic stuff in there, (i.e. polymorphism) so this should be a last ditch method.

For this to be worth doing, and in my opinion for it to gain real acceptance, two criterion must be met:

1. The real machine code that results from a compile must run as fast as any that could be generarted with a target pacific compiler.
   Or at the very least must not be orders of magnitude slower. (i.e. there should be no serious penalty).
2. In the interpreted case it must run reasonable fast.

Given all this it would be worth doing.

Re:What's the point?

[HiThere]

The problem is that MS has publically said that (paraphrase) ".NET is our IP and we intend to protect it." I never heard this statement either clarified or retracted. So I don't know what they mean, but I intend to avoid it.

Re:What's the point?

[HiThere]

I won't work on systems that claim to own my code. Thus I won't work on MSWindows. I read the EULA. I'm not a lawyer, so I don't really know how it could be interpreted, so I just took it at appearant (to me) face value.

Likewise, when a MS spokesman says (paraphrase) ".NET is our IP and we intend to defend it." and the statement is not later either retracted or explained further, I presume this means that .NET is not a safe platform to develop for.

Re:What's the point?

[AKAImBatman]

What work do you do that you need to use a BitTorrent client?

The original intent of BT: downloading ISOs and other large files. My software needs to be tested on different Linux environments, because (oddly enough) they all work different. I used to think it was sufficient to test RedHat, but then I started getting support problems on SUSE. And as I added desktop integration, I learned how f***ed up that is on Linux, and that every distro had its own way of handling it.

More like downloading movies, right you little illiterate Java zealot?

He spelled "illiterate". Huh huh. Duuuhhh...

Here's an idea. How about you grow up? That's a good little troll.

Maybe the next time you call bullshit, you can try addressing the statements made.

Why? So I can further the cause of said BULLSHIT? Java being useless because of startup times is bullshit, Bullshit, BULLSHIT. Nothing more, nothing less. And for those of us with Macintosh workstations, startup time is ZERO thanks to the shared VM.

Thanks for playing! Have a nice day! You have been trolled! I am not a lawyer, but I play one on TV! It's free, free, fat free!

Re:What's the point?

[Mike McTernan]

I suppose that the C99 'restrict' keyword will allow the compiler to assume that each compiler is pointing at a different address, and force the programmer to write code without aliased pointers, undoing my example. But the rest of C99 is about syntactic sugar and back filling deficiencies in C (e.g. long long as a defacto 64-bit type, and finally a bool type!), right?

There does not exist any high-level language that results in code that is faster than C

This is irrelevant; this doesn't say anything about it holding forever. Remember that it used to be common place to program in assembly language to get performance, but that is quite rare for all but DSP or embedded apps these days, and some of those DSP compilers are really good too. Also don't forget the higher level languages are easier to program, which is a benefit of sorts.

Maybe you should look at HP's Dynamo sometime.

Thankyou. I've looked at it a bit, and as far as I can tell it is hardware/software assist for converting code between instruction formats. I don't really see this as wholy relevant, but I guess this is all about where and when you do the compiling; interpreted programs never get compiled, .NET is compile at install on a system, Java is famously just-in-time, C and C++ are compiled once well before load/installing, and assembly code is compiled in the programmers head!

Generating low level code at different times certainly effects portability, but I don't think it really has to be coupled with performance. Hence I would love compile at install for Java, and I really like GCJ and hope it does really well too!

Re:What's the point?

[p3d0]

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.

That's not true. You make it sound like the standard dataflow optimizations don't exist. Optimizers "reverse-engineer" code to figure out what it does, then transform it into better code that does the same thing. Higher-level languages sometimes help (perhaps they provide better branch probabilities, aliasing info, escape info, etc.), but even with low-level code like quadruples, optimizers can still do a hell of a lot more than loop unrolling and peepholing.

Re:What's the point?

[p3d0]

Maybe you should look at HP's Dynamo sometime.

Thankyou. I've looked at it a bit, and as far as I can tell it is hardware/software assist for converting code between instruction formats.

Woah. You need to read past the abstract. Dynamo is quite a remarkable system that interprets already-optimized binaries on the same system for which they were compiled. It recompiles the "hot" parts (again for the same platform), and paradoxically achieves a substantial speedup in spite of the overhead of interpretation and compilation. It's a very significant piece of evidence that perhaps one day dynamic compilers will beat static ones.

The reason it's relevant is that the input language that Dynamo works on is machine code. It doesn't get much lower-level than that, and yet Dynamo's optimizer is able to do substantial optimizations even at that level. Your assertion that higher-level languages are better for optimizers is dubious, and Dynamo is one piece of evidence to the contrary.

Re:What's the point?

[Mike McTernan]

Optimizers "reverse-engineer" code to figure out what it does, then transform it into better code that does the same thing. Higher-level languages sometimes help (perhaps they provide better branch probabilities, aliasing info, escape info, etc.), but even with low-level code like quadruples, optimizers can still do a hell of a lot more than loop unrolling and peepholing.

Granted. The problem will be that the optimiser is always going to be imperfect at figuring out what code is trying to do from low level representations, such as quadruples, where some optimisations may or maynot already have been applied, especially given that different compilers will optimise differently. For the same reasons, byte code decompilers are never going to be perfect in returning original source code from byte code.

I think we both agree that compilers should, at least in theory, be better at optimising code given more hints, and this is something a good high level language should be implicitly supplying as a part of the constructs and features of language (some C compilers currently use #pragmas for compiler hints such as avg loop counts and branch probablilities).

Re:What's the point?

[p3d0]

I think we both agree that compilers should, at least in theory, be better at optimising code given more hints, and this is something a good high level language should be implicitly supplying as a part of the constructs and features of language...

Ok, I'll agree with that.

...(some C compilers currently use #pragmas for compiler hints such as avg loop counts and branch probablilities).

That solution is, I think, less than ideal. Most times, programmers don't know these things, and even if they do, they are liable to become inaccurate as a program changes or as it is used in new circumstances.

When I said the high-level language would supply branch frequency information, I was talking about things like Java's exceptions. Java compilers tend to assume that exceptions are rare, and so the optimize for the non-exception case. For instance, they assume null pointer exceptions are rare, so they remove most null pointer checks and replace them with a SIGSEGV handler. This makes the non-exceptional path much faster, but the exceptional path becomes substantially slower. In most programs, this is a big win.

One could also imagine a language that provides different conditional statements indicating different branch probabilities. For instance, "if x then y" could indicate that the probability of x is roughly 1/2, while "do y unless x" could indicate that x is more likely to be false than true.

Dynamic compilers (like JIT compilers) can do even better. Even ignoring that they may have branch frequency profiling machanisms, they can use other heuristics that help substantially. For instance, imagine a Java method has been interpreted some number of times (say 1000), and then it is passed to the JIT for compilation. If the compiler finds a reference to an unresolved class, then it can conclude that the code containing that reference never got executed by the interpreter, so it is very likely to be a cold path. It can assume that the other logic in the method is more important, and can focus its optimization efforts there.

Having the programmer annotate programs with branch frequency info seems to me like a desperate last resort.

Anyway, the point is your original statement regarding the optimizer's ability to deal with low-level languages was simply false. High-level languages have the disadvantage that the optimizer must be familiar with each construct of the language and deal with it differently. If the high-level language gets "lowered" a into uniform constructs (eg. if-then, do-unless, exception throws, and loops all become control-flow graphs with branch frequency annotations) then the optimizer can deal with them all uniformly. Otherwise, it needs to deal with an explosion of different language feature combinations to do a good job.

Re:What's the point?

[Mike McTernan]

Ok, I'll agree with that.

Thanks, Patrick.

Having the programmer annotate programs with branch frequency info seems to me like a desperate last resort.

I agree, it's not very elegant at all. This was encountered in a C compiler for a DSP, where the programmer is expected to have a good knowledge of the average inputs to a function (for example, it might be a buffer of IQ samples to be equalised), and so can give the compiler hints that it would never be able to determine through static analysis alone. For embedded work, runtime analysis and JIT is also difficult since RAM is often a restricted (it's expensive) and code maybe in ROM. If it is realtime too, it becomes even harder - which is why this compiler used #pragmas.

Anyway, the point is your original statement regarding the optimizer's ability to deal with low-level languages was simply false. High-level languages have the disadvantage that the optimizer must be familiar with each construct of the language and deal with it differently. If the high-level language gets "lowered" a into uniform constructs (eg. if-then, do-unless, exception throws, and loops all become control-flow graphs with branch frequency annotations) then the optimizer can deal with them all uniformly. Otherwise, it needs to deal with an explosion of different language feature combinations to do a good job

I don't think it was false at all, you answer how it would work in your 'Otherwise,' clause. High level languages, with features as you speculate would need a new compiler to deal with it, and certainly you wouldn't be able to write a new front end for an existing compiler and expect it to just generate optimal code from the intermediate quadruples (although it would still generate executable code); a method for processing meta data containing 'hints' as well as quads would need to be developed. In short, the intermediate language would need to be upgraded, which could be done such that existing compiler backends ignore the meta-data if not present, and front ends are not obliged to generate it. It's just like some instruction sets have bits in branch instructions to indicate whether the branch is likely to be taken or not - that is a form of meta-data.

I'm open to the idea of revolution as opposed to evolution of existing compiler technology, of which most of the break throughs were acomplished many years ago. JIT certainly has a lot to still to offer, but there are still many applications that could benefit greatly from improved static optimistaion, in my opinion.

Re:What's the point?

[p3d0]

Otherwise, it needs to deal with an explosion of different language feature combinations to do a good job.

...I don't think it was false at all, you answer how it would work in your 'Otherwise,' clause.

Writing code to deal directly with a combinatorial explosion of possible situations is never a practical approach.

JIT certainly has a lot to still to offer, but there are still many applications that could benefit greatly from improved static optimistaion, in my opinion.

I only included the info about dynamic compilation for your interest's sake. Sorry to go off on a tangent like that. My real point was that low-level languages are suitable (and in some ways more suitable) for optimization than high-level languages.

Anyway, I am also open to revolution as opposed to evolution, but I don't know what the revolution is that you have in mind. If you can give me an example of some program for which your revolutionary language + optimizer would do a better job than current state-of-the-art static compilation techniques, I would find that most interesting.

Beware, though, that there is a fine line between adding expressiveness to a language versus placing the burden of optimization on the programmer. An example of the former is strong typing, which goes a long way to helping the compiler with alias analysis. An example of the latter is #pragmas that tell the compiler how to do its job.

If you are interested, there is a language called ZPL that tries to help the programmer and optimizer work together more effectively. I think this is quite a good example of a language that does not simply put optimization burden on the programmer, but instead simultaneously eases the job of both programmer and optimizer.

Re:What's the point?

[Mike McTernan]

Writing code to deal directly with a combinatorial explosion of possible situations is never a practical approach.

As I said previously, I would expect meta-data to be added to an intermediate representation of the program such that machine code generation remains distinct from parsing and compiling. Avoiding the combinatorial explosion is just an implementation issue, which I don't see as important.

don't know what the revolution is that you have in mind.

I'm not in the business of designing new programming languages, and rarely think that making new languages is good since it is such a widely researched topic already. I don't think I'd be particularly good at it either! However, some of the syntax you mentioned earlier would be useful for explaining rough probabilities of branches, as would the ability to define pure functions where it is guaranteed that the same output will always be guaranteed from the same input. One thing I would see as useful would be telling the compiler that each time I call something such as strlen(), the result will be the same unless I've written to the input pointer (through an alias or not). I've already seen some compilers that support a __pure keyword for function declarations, and it would have been nice if that were a C99 feature too. Declaring functions with their input ranges would be cool, this is something that would fit nicely into Java (out of range values could throw an exception in a similar way to NullPointerException) and allow the compiler to better judge flow though the function, or replace it with a lookup table (depending on speed/size optimisation setting) if it were a pure function.

It would also be nice if a construct similar to switch statements were to be provided where it was possible to indicate which events are most likely to happen; currently the compilers I've experienced determine if the switch statment is 'dense' or 'sparse' and decide to generate either a lookup table or a number of tests in sequence. Certainly, given the probabilities of various options, a compiler could decide how to order serial test to be most efficient in testing the most frequent match first vs generating the constants to test against eg.

switch(x) {
case 'a': .... break;
case 'b': .... break;
case 'c': .... break;
}

It's easy to compare against 'a', then add 1 to 'a' and make the next test, and so on, but it might be better to compare against 'c', deduct 2, test 'a' and then add 1 to test against 'b' last. Certainly runtime analysis could help determine this, but as mentioned before, JIT isn't always viable for every situation. I'm not even sure that Java or C require serial tests for a switch statement to be in declaration order, if it did then that would be somewhat useful at least. Two types of switch statement might be good, a 'switch' where the compiler is free to determine the test order, and a 'shunt' (don't laugh!) where the test order is meaningful (but could be ignored by the compiler if required or better optimisation is possible for other criteria).

I'm sure that there are other examples of places where interesting hints could be provided in a non-intrusive manner, and you probably have a good idea as to some too.

RE: ZPL - it sounds like an intersting language. I'll look into, along with HP's Dynamo - thanks for the suggestions :)

Re:What's the point?

[p3d0]

Avoiding the combinatorial explosion is just an implementation issue, which I don't see as important.

I'm not sure you're getting my meaning. When you're dealing with an optimizing compiler, you can drown in "implementation issues". Optimizing compilers are already some of the most complex programs in existence.

Let me illustrate. Suppose a language has all the conditional constructs I mentioned: if-then, if-then-else, do-unless, try-catch. Further, suppose it has a few loop constructs: while-do, do-while, for-do.

Now you study your program and find this loop is hot:

if(limit < array.size) then {
for(a=0; a < limit; a++) do {
array[a] = 0;
}
}

(Sorry about the indentation.)

You discover that the loop is wasting time testing a against the array bounds, when you can tell by inspection that this is not necessary. So you construct an optimization that looks for array accesses by induction variables inside for-loops, then check if the loop is contained in an if-then statement which puts a limit on that induction variable, and finally make sure the limit itself is within the array bounds. You spend three days coding and testing this optimization to make sure you haven't forgotten any corner cases. During your testing, you discover that you forgot to make sure the vatiable array doesn't change between the if-then test and the inner loop.

Now, it occurs to you that you could generalize this so it works for any loop inside any conditional. That means 12 different combinations. You can check the loop and the conditional separately, so that's really just 3+4=7 tests you need. Still, that's 5 more tests than you needed before you generalized it.

Then you realize you could catch another case if you tweak your optimization more:

while(limit < array.size) do {
for(a=0; a < limit; a++) do {
array[a] = 0;
}
}

This is not a loop inside a conditional, but a loop inside another loop. Ok, so you add this to your tests, bringing the total number of tests to around 10. Oops, you just realized that this doesn't work if the outer loop is a do-while loop. Make that 9 tests.

Now you have done all this thinking and all this work. I have two questions for you:

1. Is this optimization as good as it could be? Could further tweaking improve it substantially?
2. Is the optimization correct?

You should find these two questions hard to answer, and that should be very worrisome. This kind of "implementation detail" is enough in practice to turn a poorly-designed optimization engine into a useless pile of crap.

Now consider an alternate solution: model the program at a lower level, as a control-flow graph containing quadruples, and annotated with use-def and def-use chains (which can be derived from the CFG and quads, so that's not really cheating). No space to describe these further here; see Google or a text on optimizing compilers.

The optimization becomes a matter of (1) running a dataflow pass that finds all conditional nodes in the CFG and propagates constraints to the blocks inside the graph, and (2) checking the constraints at each array access to see whether the bounds check is necessary.

This has become a fairly routine dataflow analysis. It can find all the unnecessary bounds checks of the first approach, and many more (eg. those that are not within loops), yet it is much simpler to write, to test, and to reason about.

Again, I'm not an optimizer expert (I work on a compiler back-end), but I hope this gives you a feel for why higher-level is not necessarily better when it comes to intermediate languages. It's important not only to have all the necessary high-level information, but also to abstract away irrelevant differences so that the compiler can easily find opportunities for optimization.

And also consider that a lot of very smart people have spent a lot of time on the optimization problem. If you think you can do better, you should make sure you understand the current state of the art first.

XML ?

[noselasd]

Did I see XML and performance in the same sentence ?! ... brain overload.. does not make sense...

Re:XML ?

[Anonymous Coward]

Good god. XML is VERY VERY good for what it was designed for: semantic markup of texts. It is not very good as a straightjacket on a programming language.

Re:XML ?

[Da Fokka]

The days that loading binaries from disk into memory was a significant performance hit are long gone...

Re:XML ?

[benjamindees]

I saw that too.
Then I saw Posted by michael and everything was better.

Re:XML ?

[noselasd]

Indeed it is, still, people want to use it for just about anything it _wasn't_ desgined for. ;-(

Re:XML ?

[mabinogi]

That may be true, but XML would be a great way to bring them back!

Re:XML ?

[mrogers]

The days that loading binaries from disk into memory was a significant performance hit are long gone...

Haven't used Mozilla recently, have you?

Re:XML ?

[squiggleslash]

XML is not for the semantic markup of texts. That's HTML and its XML equivalents. XML is a way of encapsulating structured data in a text format that's "easy" to parse.

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.

Re:XML ?

[tomstdenis]

Or open office. Sure while it's all in the cache it loads quickly but the first time is always a 20 second delay I could do without.

Tom

Re:XML ?

[You're All Wrong]

XML is not for semantic markup of text. It's for structured representationof data. And it's just a butt-ugly version of lisp s-exps were 4 decades ago.

YAW.

Re:XML ?

[PetoskeyGuy]

Hey - Maybe it does.

The only way to get performance out of XML would be to have IBM, Sun or Cray making XML cards. Like how graphics cards speed up 3D rendering to the point of almost real time ray tracing. Load your DTD and XLST into you XPU - XML Processor Unit and fire away.

I know it's just some weird delusion of the poster - the article mentions nothing about it. How hard would it be to create your own XML processing hardware? Would it be faster and what would it do?

Re:XML ?

[Malcontent]

I read someplace that there is nothing that XML can do that Lisp can't. Maybe they are talking about remaking lisp again.

Re:XML ?

[leandrod]

> XML is not for the semantic markup of texts. That's HTML and its XML equivalents.

Not. XML is just simplified SGML, and SGML is for semantic markup of texts. All else is misuse. Markup of data is just stupid. Binary, tables in sequential files with associated field descriptions, all that can be very simple to parse, proviede there is a DTD, which is no invention of SGML. SGML for data is inefficient processing for computers and too much noise for humans.

Re:XML ?

[Bombcar]

<CODE LABEL=START>
<INSTRUCTION=MOV>
<MOV_TYPE=REGISTER>
<DESTINATION=REGISTER>
<REGISTER BITS=16>
<REGISTER NAME=AX>
</DESTINATION>
<SOURCE=REGISTER>
<REGISTER BITS=16>
<REGISTER NAME=CX>
</SOURCE>
</INSTRUCTION>
</CODE>

Re:XML ?

[LarryRiedel]

A few quotes from Charles Goldfarb related to the origins of SGML and XML.

• Unlike other pioneers in this area, my chief motivation was information retrieval, not typesetting.
• The areas of publishing and information retrieval are often thought of as comprising distinct applications for a computer system. In fact, the functions of the two overlap significantly, and both could be served best by an integrated system

• Q: There's the SGML community, and then there's the HTML community. So, the HTML authors fear that their world of static elements is about to get a lot more complicated.
  A: Now, you know they don't know those are called elements. They call 'em tags [chuckles]. But there's also a third audience, which is maybe even bigger than the other two: the people who want to shift data around. Jean Paoli told me that he sees the biggest users of XML being the guys who write Excel spreadsheets, and want to get data from their company's mainframe or from a Web server belonging to one of their company's suppliers or customers

  Q: So, not just document exchange, but application exchange of data.
  A: Absolutely! And, you see, not just documents, not just publishing. There's an important distinction there. These are all documents in the sense of the way that word is used in the dictionary. The key is recognizing that XML is a data representation that has the characteristics of a document. That's where the real power comes in, because [you can] process it as data by first parsing it to extract the data or you can present it the way you would a document. And you can do both things in the same application at the same time. That's the real breakthrough

I think XML is a good neutral format for representing information which has a sequential and/or tree structure, like computer program code.

Larry

Re:XML ?

[Pseudonym]

I just wish IFF had survived the death of the Amiga as a mainstream platform.

It did. IFF (in a quite extended form) is still the binary format used by Maya.

Re:XML ?

[kurt_cagle]

(Trying this again)

Aarggh -- if you're going to doing this, do it right:

<code label="start">
<instruction name="MOV" type="REGISTER">
<source bits="16" name="CX"/>
<destination bits="16" name="AX"/>
</instruction>
</code>

Re:XML ?

[Bombcar]

Ah, sosumi. The only thing I know about XML is that slashdot eats it 'cuz it looks like HTML.

Re:XML ?

[tedgyz]

Don't you know? XML is the solution to EVERYTHING!

Re:Next try?

[be-fan]

Eh? I think that's a large coffee at Starbucks. I think it goes "Java short," "Java tall," and "Java grande."

but the biggest question is...

[b17bmbr]

The effort is part of a government-sponsored program under which the three companies are competing to design a petascale-class computer by 2010.

will sun survive until then?

Is intermedia language really needed for OS

[vvdd2]

Is intermedia language really that useful for Open Source Software? To run on any CPU is one of the biggest opportunities for Linux/Apache/Emacs/etc. the only thing which changes - a compiler. Open Source software gives a good chance for a new computer architecture. May be an intermedia language is not that useful after all?

Re:Is intermedia language really needed for OS

[vvdd2]

You are not supposed to do porting and compilation. The vendor (RedHat/BSD team/SUN/IBM/etc.) supposed to take care of this, and they do porting well. If you have enough resources to build a new CPU it should not be a problem for you to take care about headers and #ifdefs.

Re:Next try?

[Bender_]

I already found the info on http://www.javagrande.org/. But indeed the website says:

"There are currently no plans for a full meeting in 2003."

So it is probably over already.

GCC

[norwoodites]

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.

Re:GCC

[pcause]

Su didn't invite GCC developers to the meeting becuase Sun wants control, like they tried to have with Java. Just look at the history and how Sun fought, tooth and nail, to avoid letting anyone else have any input.

This effort is all about Sun trying to gain some new market edge and control. The HPC market is one in which MS is not currently a player. It may be the only market left where Sun doesn't have to compete against MS. In this market Sun competes with Cray and IBM and thinks that they know how to beat those guys.

Hopefully, IBM and Cray won't be fooled. They've competed with Sun for year and, even though the evidence is contrary, perhaps they've now learned not to trust Sun at all.

Re:GCC

[Grizzlysmit]

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.

hmmm would the intermediate form you use in gcc work for this, how high level is it, and what is in the .o file I always thought machine code.

Or...

[FrostedWheat]

Create a sort of meta-CPU that can be self-programmed to emulate other processors. Transmeta where close.

That way it wouldn't really matter what processor a program was complied for. Is such a thing feasable? Or am I showing how little I know about CPUs here? :)

Re:Or...

[benjamindees]

I think you're just showing how little you know about the profit motives of big hardware manufacturers.

They want to kludge the software to make it work with their hardware, not the other way around.

Buzzword compliance

[ajs]

I really hope the author's smiley was to indicate that he understood that his string of buzzwords was meaningless.

What I hope is that Sun takes a good, long look at the only intermediate assembly that has been designed with language neutrality in mind, Parrot. While this article is over 2 years old, it's a decent starting point. Parrot has already been used to implement rudimentary versions of Perl 5, Perl 6, Python, Java, Scheme and a number of other languages. The proof of concept is done, and Sun could start with a wonderfully advanced next generation byte code language if they can avoid dismissing Parrot as, "a Perl thing" with their usual distain for things "not of Sun".... IBM on the other hand is usally more open to good ideas.

Re:Buzzword compliance

[Tim C]

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.

Re:Buzzword compliance

[penguin7of9]

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

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

Re:Buzzword compliance

[marnanel]

Have things much improved since AMK's post about why he was stopping Python Parrot development, then? I'd been following the development of Parrot for Python with some interest at that point, but after I saw the arguments put forward in that post I'd assumed that non-Perl Parrot development was all over, at least for a good while.

(Googling on this now, I find that someone else was working on Parrot for Python at least six months ago, so I guess I shouldn't have given up hope.)

Re:Buzzword compliance

[h2odragon]

i intended to flame AMK for his interest in XML, and you for citing him as an authority... but damn, he's right. Parrot aspires to be a toy for design wankers.

Re:Buzzword compliance

[Pseudonym]

What I hope is that Sun takes a good, long look at the only intermediate assembly that has been designed with language neutrality in mind, Parrot.

I hope they do too. An intermediate assembly language with actual registers would be an excellent thing.

I hope they don't just copy it, though. I've tried writing an optimiser for Parrot (I'm a compiler hack by trade) and I failed miserably. Parrot is defined for fast interpretation and good quality JIT, not for IL to IL optimisations. Not that there's anything wrong with that.

Re:Buzzword compliance

[kiniry]

I am afraid that you are mistaken. There have been several intermediate languages designed with language neutrality in mind, most of which are much older than two years.

My two favorites are the high-level representation form available in ANDF (over a decade old), and the typed functional approach of modern meta-complier frameworks like the Mohave system at Caltech.

In any case, I do also hope that Sun and related parties get experts on this precise topic involved so that the huge amount of research available in the field will not go to waste.

Re:Buzzword compliance

[Grizzlysmit]

What I hope is that Sun takes a good, long look at the only intermediate assembly that has been designed with language neutrality in mind, Parrot. While this article is over 2 years old, it's a decent starting point. Parrot has already been used to implement rudimentary versions of Perl 5, Perl 6, Python, Java, Scheme and a number of other languages. The proof of concept is done, and Sun could start with a wonderfully advanced next generation byte code language if they can avoid dismissing Parrot as, "a Perl thing" with their usual distain for things "not of Sun".... IBM on the other hand is usally more open to good ideas.

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

Ummmm how does Parrot go at being compiled to real machine code, without that it's not even a contender in my book, the article you link to say it's for dynamic languages "we'd like Parrot to become a 'common language runtime' for dynamic languages", I personally would only be interested if it was for both dynamic and non-dynamic languages.

I wouldn't use it unless it could be used as a step in the process of compiling a C/C++ program, and produce code at least as fast as gcc, would. But if it can do that, then I would suggest that SUN just pitch in and help make Parrot the standard their looking for.

Re:Buzzword compliance

[ajs]

Thanks for the great examples. Glad to see someone who knows the field better than I do is paying attention and keeping me honest!

*SIGH*

[mike3k]

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.

Re:*SIGH*

[btakita]

But XWindows doesnt...

Re:*SIGH*

[angel'o'sphere]

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?

Yes, it is. And for long running applications, like amazon.com, its faster.
And ... amazone.com was developed in a considerable and affordable timeframe, in assembler they would code still today.

angel'o'sphere

ANDF?

[myg]

What about the Architecture Neutral Distribution Format from the TenDRA project?

That format could be extended into a vendor-neutral format for both interpretation, just-in-time compilation, and batch compilation.

Need more info...

[devphil]

The article is very light on details.

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.

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.

Maybe now I won't have to write my neural network in C for performance :-)

Odd. I wouldn't have thought you'd need to do that these days anyway.

Re:Need more info...

[devphil]

Easy to see why you're a troll. I never recommended Java. I never said any of the things you attribute to me. I said that I was surprised that you still think C is required for good performance (having obtained good neural net performance with not-C in the past). That's all. That leaves a lot of other languages besides C and Java.

I sense a constant argument between yourself and your coworkers over the use if Java. If you need to have that argument here on slashdot, fine, but don't put words in my mouth or place me in positions where I have claimed no place.

Now what I would like...

[SharpFang]

a language that feels like medium-to-high level (like, say ANSI C) but is in fact assembly - for certain new CPU. Can be run over VMs like Java or other cross-platform languages, can have other "metalanguages" built on top of it (like C++ or Perl on top of C) and is crossplatform for 'generic' platforms - but there exists a platform which is native for it, so bytecode can be run on it without any VM. Just perfect for embedded applications etc, while not leaving PCs and other "desktop boxes" out. (plus you can plug a "dedicated CPU" as a booster card in PCI and have it run its native apps at full speed without any load on your "main" CPU, just like the MPEG2 encoder cards did)

Re:Now what I would like...

[foonf]

a language that feels like medium-to-high level (like, say ANSI C) but is in fact assembly - for certain new CPU.

This is kind of nonsense. It cannot really be "assembly" (at least in the normal sense in which assembly is defined, where there is a 1-1 or close to 1-1 correspondence between instructions in the language and machine instructions) if it supports things like procedures, nested complex arithmetic expressions, and named variables, and no sane high-level language can be without those things. Representing them in any kind of machine language that can be run on real hardware absolutely requires an intermediate parsing stage. Even Lisp machines couldn't literally run Lisp code in hardware, they just had certain architectural features that made implementation of a Lisp system more efficient, and the trend now is toward simpler architectures and more aggressive optimizing compilers, resulting in a wider gap between the high-level and bytecode representations of a program. Modern attempts to build hardware executing high-level representations directly, like some of Sun's attempts at processors running the Java bytecode language directly, have not had competitive performance.

Re:Now what I would like...

[moneymaker]

Well Portable.net does seem to have a pure IL C compiler. And there was something called "Jindalee" discussed for development , which would have a Virtual Machine but still run at almost native speeds . Never worked out anyway .. nobody was interested.

Reminds me of the old quote...

[Waffle Iron]

"There is no problem in computer science that cannot be solved by adding another layer of indirection."

Re:Reminds me of the old quote...

[cant_get_a_good_nick]

"There is no problem in computer science that cannot be solved by adding another layer of indirection..."

". . . except for too many layers of indirection."
-- addendum (possibly by a Java or C# programmer).

high-performance computing

[Via_Patrino]

I don't think they're trying to create a language for "high-performance computing" but a language for a "high-performance multi-processor computer", since they're focusing on threads and sun isn't a very good example (jvm) of high-performance.

In my opinion I would like a C language variation that let me specify how many bits i would like to use for a variable, because it would save a lot time because of memory bandwidth (cache space included) and is very boring to make a good implementation of that in assembly.

Re:high-performance computing

[kasperd]

I would like a C language variation that let me specify how many bits i would like to use for a variable

In C we already have types like uint8_t and int16_t. In addition to that you can use bitfields for fields in your structs. What more would you ask for? Remember, that often extra space is actually added between your variables, for performance reasons. Alligned access is faster than unalligned access.

Re:high-performance computing

[Jimmy_B]

In my opinion I would like a C language variation that let me specify how many bits i would like to use for a variable, because it would save a lot time because of memory bandwidth (cache space included) and is very boring to make a good implementation of that in assembly.

You're joking, right? C has officially had that (bit-fields) since '99. And any time the number of bits is not either 1 or a multiple of 8, it's much, much slower than it would be otherwise, because despite any difference in memory/cache usage, extracting strangely-aligned data is slow and awkward. Variable sizes that aren't powers-of-2 number of bytes are bad not because of any language, but because no sensible hardware supports it in any reasonable sense.

Re:high-performance computing

[UserGoogol]

Those should be unsigned ints. Otherwise, the only integers you can store in YouSuck.a are -1 and 0, not 0 and 1 as one would expect and usually prefer.

Re:high-performance computing

[Via_Patrino]

And any time the number of bits is not either 1 or a multiple of 8, it's much, much slower than it would be otherwise

Not that much, if i use padding to keep variables inside of less bytes possible (example: keep a five bits vaiable inside one byte, not two) i can recover data using OR and shifts, that are quite fast.
And if i can dig in assembly i can make the operations without shifts.

What struck me was this

[Anonymous Coward]

"I wonder if the format will be in XML? [...] Maybe now I won't have to write my neural network in C for performance"

Is he on crack? :-)

Re:Just what we need...

[bersl2]

They might as well try to write a a pseudo-code compiler and take this thing to its logical conclusion.

That's elementary, Watson.

[SharpFang]

Why?
1) Learn the new language well.
2) Find some sucker who will employ you, or other ???
3) Profit!!!
4) For money earned, employ programmers from India to write your neural network in assembly for performance.

Parrot assembly?

[Ars-Fartsica]

I thought an open, peer-reviewed, high performance IL/runtime was exactlywhat Parrot was trying to accomplish.

Re:Parrot assembly?

[glenstar]

No, no, no... Parrot is to be the native IL of the Hurd. It should be interesting to see which if finished first.

Re:Parrot assembly?

[cant_get_a_good_nick]

Perl, not the HURD

Re:Parrot assembly?

[Lost2Home]

Miguel of Ximian/GNOME fame was quoted as saying that Parrot is a religion, not a real software project.

Sure he did.

Try looking a little harder next time.

Re:Parrot assembly?

[glenstar]

Stupid me, I forgot the smiley.

Re:Next try?

[elton247]

The large is called Venti, Grande is the medium size. Short is like the drink size you get with a Happy Meal at Micky D's.

what is new about this??

[esj at harvee]

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.

Re:what is new about this??

[argent]

They can't use TenDRA, 'cos the OSF was involved in it and they're still pissed off about Motif.

Re:what is new about this??

[esj at harvee]

as always, ego before excellence..

Re:Next try?

[The Lynxpro]

"One thing puzzles me, however. What is Java grande? Was it so shortlived that I missed it?"

Better yet, where is Java Venti?

If you stop and think about it, what could a Sun/Starbucks partnership entail? The Starbucks card working on the SunRay platform, taking your virtual login identity to every Starbucks location you frequent? Even better to realize that just about all Starbucks locations have WiFi hotspots. Oh the conspiracy!

Please clarify

[Anonymous Coward]

Is it the 'XML' and 'performance' or fact that you found a complete sentence on Slashdot sending your brain into overload?

Re:Just what we need...

[Raiford]

seems like everyone is getting hung up on the buzzwords and missing some significance here. Regardless of what it may look like at least someone out there is raising an important issue. There is a need for a good current generation scientific programming language. The last decent one was Fortran 77. No incarnation of Fortran has really come close to its utility because of the misguided effort to make it look like C++. Java, C++, C, etc are not scientific programming languages. There is a need for something new.

Cheer up.

[SharpFang]

Quite insighful... but it isn't as bad as it looks.
1) Nobody forces you to write in Java for PIII. Write hand-optimised asm sniplets for PIII and include them in bigger Java or C app for time-critical pieces. You get real PIII performance.
2) The software quality drops, but slower than CPU speed rises. That means your Java app for PIII will still work -slightly- faster than hand-coded ASM for 486.
3) Development cost. You can spend a week to write a really fast small piece of code in ASM. Or you can spend that week on writing quite a big, though slow app.
Most visible in games. Things like Morrowind, where crossing the map without stop takes a hour or more, and exploring all the corners is months of play, were plainly impossible when it all required hand-coding. Now for a developer it takes shorter to create a mountain in game than for a player to climb it. Of course the player needs better CPU to be able to display the mountain which wasn't hand-optimised, just created in an artificial high-level language defining the game world, but if you're going to enjoy the experience - why not?

Re:Cheer up.

[MooCows]

Things like Morrowind, where crossing the map without stop takes a hour or more, and exploring all the corners is months of play, were plainly impossible when it all required hand-coding

You forgot to mention that Morrowind was buggy, slow, crashed often, and had horrible loading times. ;)

(was a great game anyways)

Re:Cheer up.

[shplorb]

Now for a developer it takes shorter to create a mountain in game than for a player to climb it.

Yeah, that's why it takes thousands of man-hours to create a game that you can play through in 40 or so hours.

Why wonder if it will be in XML?

[Anonymous Coward]

Are you in management?

I would imagine that the data for this new IL would be very uniform, like assembly. Unless they plan on adding gobs of metadata, there is absolutly no need for XML. XML is very useful tool, but don't forget that if you give someone a hammer then everything will look like a nail.

Would you represent an array of bytes using XML just because you can? This IL will most likely be a sequence of well-defined binary tokens. What would it benefit from XML? Maybe programs/functions/classes can have some XML metadata, but the actual sequence of commands will most likely be a chunk of binary data.

If it was useful/practical to have an IL language specified in XML, then Microsoft would have done so with MSIL already. BTW, don't bother bashing MS about the usefulness and practicality of their products. MS has some brilliant engineers so at least give them some credit for trying to make a decent IL.

Re:It's already done and is called hyperthreading.

[FrostedWheat]

It's already done and is called hyperthreading.

Hyperthreading is just a way to squeeze a bit more performance out of a CPU. It itself has nothing to do with the instruction set.

I wonder if the format will be in XML?

[chaoticset]

So you mean Flare?

XML? I hope not

[rjamestaylor]

• I wonder if the format will be in XML?

Putting byte-code in an overwhelmingly verbose text-oriented format? I'd expect such a suggestion from CPU manufacturers, but few others.

The problem is with the high level,

[Circuit Breaker]

The problem is with the high level languages, not with the intermediate ones. If the source is C, efficiently vectorizing it is a problem that will not be solved by a new intermediate representation. And if it's a new high level language - well, we'll need to design the IL with respect to that HLL.

APL, J and K are three languages that could be considered IL for high performance computing. But they're high enough to write code directly in them; And so far, it seems, implementations do a wonderful job without compiling down to machine language.

AOS

[scode]

Everyone interested in this might want to have a look at AOS, one of the two platforms (CLR/.NET being the other) targeted by SmallScript/S# at
www.smallscript.net.

I am not that well informed, but as I understand it AOS is essentially a more generic and language neutral alternative to CLR.

Am I really so much outdated ?

[foobsr]

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.

I ever since hearing of CMs up to now thought that issues were parallelizing compilers and languages enabling application specific concepts (e.g. "A High-Level, Massively Parallel Programming Environment and Its Realization") Is this so much outdated ?

CC.

P.S.: Besides, this must have been the result of a paraphrasing engine ... erm script effort like mentioned in another 'thread' (/.).

UCSD Pascal

[Detritus]

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.

C-Bonics

[Epistax]

I propose that this intermediate language be called C-Bonics, and it should be taught in all classrooms in place of C. Many people don't learn proper C in their homes so it isn't fair to force them to do it in school.

Re:C-Bonics

[p4ul13]

A Haiku:

Comment amused me,
It delivered mirth to me.
Mod the parent up!

-Me

Which languages are the major players these days?

[Null Argument]

I know it depends on the use of the program in question. Just curious what other people's opinions are.

Re:Next try?

[Anonymous Coward]

Java is still alive and doing well.

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 :-))

Grid

[AaronGTurner]

There are several issues with regard to current programming techniques and grid computing for HPC. Some include:

• Legacy code - both user code and 3rd party libraries such as NAG.
• Matching OSes. Java alleviates this to some extent at the expense of performance . Also not all JVMs are equal. If you can use more resources then slower, less efficient execution isn't such a problem. I.e. a balance between ease of use and code efficiency. Good java code helps!
• Matching executables and dynamic libraries. Static compilation helps.
• Matching system capabilities for additional tools, such as MPI, PVM etc
• Licensing
• Data replication, transfer, etc

Java isn't a bad way to offer the capability to run your code on many platforms, but it is easy to write slow code that really doesn't match the HPC speed requirement, although some do use it for HPC. Faster bytecode or JVMs that do ecen better at optimising bytecode would be a help, but I am not sure if there is enough algorithmic information left in the bytecode to allow the best optimisations on all architectures. Perhaps this is where the new initiative is aimed?

An alternative route is to publish capabilities for processing via web or grid service type mechanisms and then use brokers and discovery services. This would work well for widely used production codes, e.g. charm, fluent, etc

64bit Ints and 128 bits Longs

[DrTung]

Hopefully this time they will declare the standard integer size to be 64 bits (and long ints 128 bits). This will make some stuff easier, like calculating # of free bytes on a hard disk, using GUIDs for webshops etc.

Re:64bit Ints and 128 bits Longs

[Anonymous Coward]

Or just enable automatic overflow into arbitrary precision bignums like lisp has had for several decades now...

too little, too late

[penguin7of9]

The effort is part of a government-sponsored program under which the three companies are competing to design a petascale-class computer by 2010.

We already have such a runtime: it's called "CLR". The CLR is roughly like the JVM but with features required for high performance computing added (foremost, value classes).

Sun wants the so-called Portable Intermediate Language and Run-Time Environment to become an open industry standard.

I hope people won't fall for that again. Sun promised that Java would be an "open industry standard", but they withdrew from two open standards institutions and then turned Java over to a privately run consortium, with specifications only available under restrictive licenses.

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's "expertise" in this area is not a recommendation: the JVM has a number of serious design problems (e.g., conformant array types, arithmetic requirements, lack of multidimensional arrays) that attest to Sun's lack of expertise and competence in this area.

What this amounts to is Sun conceding that Java simply isn't suitable as a high-performance numerical platform and that it will never get fixed (another broken promise from Sun). But because the CLR actually has many of the features needed for a high-performance numerical platform, Sun is worried about their marketshare.

The question for potential users is: why wait until 2010 when the CLR is already here? And why trust Sun after they have disappointed the community so thoroughly, both in terms of broken promises on an open Java standard and in terms of technology?

Maybe we will be using a portable high-performance runtime other than the CLR by 2010, but I sure hope Sun will have nothing to do with it. (In fact, I think there is a good chance Sun won't even be around then anymore.)

Re:too little, too late

[Baki]

Do you have real experience with JVM versus CLR real world "high performance computing"? I bet not, since otherwise you would not have written this. There may be a lack of value classes and multi-dimensional arrays as compared to CLR, but the JIT is better. Various benchmarks have shown 10-20% faster execution speed for JVM versus CLR. .NET is only faster when it comes to GUI's, because of greater usage of platform dependent (native) code.

If SUN extends the intermediate language specifically targetted to high speed computing, the advantage shall even increase.

Why use the CLR, when the JVM is already faster?!?

Re:too little, too late

[Haeleth]

Various benchmarks have shown 10-20% faster execution speed for JVM versus CLR.

Citations, please.

No, I'm not going to google for it myself; you're the one making the claims, it's your job to support them.

Re:too little, too late

[earache]

Everything I've read has been to the contrary of what you are stating.

Can you point to anything to substantiate your claims?

Re:too little, too late

[Baki]

Apart from my own benchmarks (I have done benchmarking professionally and still like to do some benchmarks now and then) which I did not publicize, google for jvm clr benchmark delivered a.o.:

http://www.jroller.com/page/cpurdy/20030519

http://www.manageability.org/blog/archive/200305 20 %23p_the_problem_with_cameron/view

http://www.kuro5hin.org/story/2002/6/25/122237/0 78

just to mention a few.

Really, look for yourself. The only ones that have clr/C# win are sites that are either affiliated with MSFT or generally pro windows.

I have tested some classes of problems myself (mainly cellular automata such as the Game of Life etc.) and found recent JVM versions to reach about 80-90% of raw C(++) speed, and having a lead of about 10-20% on C#.

I keep wondering why so many people assume that C# is faster. Why do so many people, even on slashdot, blindly believe MSFT propaganda without even doing some research or benchmarks for themselves? That is really frightning.

I admit I don't know the details of neither JVM "machine language" nor CLR, but independent benchmarks, both "real world" and syntetic ones, consistently show the lead that the JVM has, despite of MSFT propaganda.

Re:too little, too late

[penguin7of9]

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.

who cares about who Sun invites?

[penguin7of9]

I don't see how Sun is even relevant or why it matters who they "invite". They had their chance with Java and they blew it. I doubt the numerical community is going to give them another chance after what they have been through with Sun over the last decade.

I suspect the next intermediate language for high-performance numerical computing is either going to be the CLR, some extension of the CLR, or something entirely different, developed in academia.

This could have cool implications

[Omega1045]

Even if other big players like MS do not participate, this could really be cool for cross-platform applications. Imagine a caching JIT for such a language. Now imagine a converter that could take Java or .NET assemblies and convert them to this new "byte-code". I am sure a 3rd party would step-up to write the MS version!

Now we are talking! I want my C# to compile to native code on Linux, Sun, and IBM mainframes. I want to take Java programmers in my firm and have their code call my C# and visa-versa. This could be a big step towards that.

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.

No, this is about Sun control

[Ars-Fartsica]

Sun just wants to inject Java into yet another domain space where it isn't needed or wanted. Let me guess - the Sun proposal will be Java bytecodes.

SUN does not understand High Performance Computing

[Anonymous Coward]

Having tried to write HPC apps in Java, there are some very serious problems with the current JVM.

1. Lack of scientific data types, such as complex numbers.
2. Lack of multidimensional arrays.
3. Inept implementation of floating point arithmetic.
4. Poor choices for defaults, such as array bounds checking and pretty printing ascii I/O.
5. Onerous penalties for JNI calls and serialization.
6. Intermindable process for correcting deficiencies with the language.

SUN has not displayed an understanding of HPC. Adding OpenMP or other "HPC" friendly capabilities to the VM is not going to correct design decisions with remove performance from "High Performance computing.

Re:Next try?

[bckrispi]

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.

XML?

[CatOne]

Why, so intermediate files can be 100 times larger than they already are? :-P

With the only penalty being "hello world" is 7 meg

[rs79]

IL codes are neat. I hope they look at Tannenbaums work.

Mod parent up

[Anonymous Coward]

That is right on the money. Sun is trying to make an alternative to the CLR - a blantant attempt to take back developers who've switched from Sun J2EE to MS .Net.

Now, I'm all for having alternatives, but what's going to happen to Java? Will Java compile to IL? The Mono project and DotGNU project both have plans for compiling Java to IL, allowing .Net and Java apps to talk to each other natively - why then is Sun developing yet another IL standard? The Common Intermediate Language, the ECMA standard which is used by both .Net and Mono, is the only IL we need. On the other hand, building multiple implementations of the standard IL for running on different operating systems is where Sun should be focusing their efforts.

Only if Sun's IL interoperates with the Common Intermediate Language will I be rooting for Sun.

My God, they've reinvented CADOL

[rs79]

Why is it I find PARROT more readable than Perl?

Re:My God, they've reinvented CADOL

[Artifakt]

Well of course! Wasn't the motto of the first annual obfuscated Perl competition "Every contestant a winner"? :)

*Sigh* how will decimal ruin this.

[Thinkit3]

How much time wasted converting? How much elegance lost to decimal?

Re:*Sigh* how will decimal ruin this.

[jared_hanson]

Do you even know what you are talking about anymore?

Intermediate languages are essentialy a processor independant instruction set. You compile down to this instruction set and then let the virtual machine translate to the native instruction set, hence cross platform. These intermediate languages are binary and have no concept of decimal or hexidecimal.

LLVM?

[shnarez]

Why not just use something like LLVM and/or extend it instead of re-inventing the wheel?

LLVM is already made to be low-level (like assembly language) but with high-level types (struct, int, array) like high-level languages. Sounds like just what they would want.

FREE YOUR MIND!

[SharpFang]

Don't limit your imagination to bounds of i386-compatibile architecture!

Ever thought about writing interpreter or VM in VHDL and implementing it on a FPGA board? That would be pretty similar.

>if it supports things like procedures
Stacks substituted for local variables, CALL, RET, what a problem?

>nested complex arithmetic expressions,
Can be un-nested at compile time, not really going far from assembly. Just remember that each +, ( or % is a separate call. Can be RPN, why not? That's very close to assembly.

>and named varables
Is it a big problem in assembly? Just pick a register or memory cell and give it a name.

>and no sane high-level language can be without those things.
Implementing some of those in compiler (ASM needs compiler too!) and the rest in hardware is far from impossible :)

Simply start the design not like with modern languages "We need commands that do this, that and that" and then try to fit them into existing hardware through compilers, but build a hardware that can perform your basic commands directly. So if I call fork(), I don't get a ton of system commands launched, just a single CPU cycle gives me a nice copy of the process and it runs _really_ simultaneously, not by time-sharing. If I want to send signal to some other process, it doesn't go through several levels of OS indirection, it's handled by the hardware, like a hardware interrupt. To perform write() and consider it done in one cycle, or at most as many cycles as many characters i'm writing(). by having my Of course I'm limited by the hardware on how much I can do, but isn't that the case always? Just that next to limits on RAM and CPU speed I get limits on number of variables, number of processes etc? (especially if I can make those dynamic limits, buy better chip, get more processes)
The problem with C is that it's -a bit- too far from the hardware. A bit too much goes on without programmer's knowledge. How do I know ++ operator is 1-cycle CPU INC command or a 300-cycle call to math library to perform addition? I want to be able to select a chunk of code and see CPU cycle count. To have granted command execution time.

English as an intermediate language?

[rice_burners_suck]

I propose that the new high performance intermediate language be English. You would code in it as follows:

Computer, please allocate some room on the stack for a variable, and please call that variable 'i'. Thank you, Computer. Now, computer, please set the value of the aforementioned variable, 'i', to zero. Thank you, Computer.

..... I don't have the patience to write more of this crap.

Re:English as an intermediate language?

[NickFitz]

I don't have the patience to write more of this crap

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 ( - )

player explodes
mine explodes
thing_at_top explodes
thing_at_side explodes
bubble bursts ;

FWIW, "bursts" was a convenience word used to make it read better. Its definition was:

: bursts (thing_to_burst - )

explodes ;

(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 :-)

Re:With the only penalty being "hello world" is 7

[JeanBaptiste]

troll that which you do not know...

This hello world program comes in at 7680 bytes as an executable...

Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
MsgBox("Hello World")
Me.Close
End Sub

granted there is the 20 meg framework package, but really thats nothing these days, and that 20 megs supports a lot more than 'hello world'...

like it or not, its not as terrible as other things we have seen from ms.

so let me get this straight...

[Kunta Kinte]

The question for potential users is: why wait until 2010 when the CLR is already here? And why trust Sun after they have disappointed the community so thoroughly, both in terms of broken promises on an open Java standard and in terms of technology?

You don't trust Sun, so you're recommending...

Microsoft????

Ohh-kayyy..., next post please.

Re:so let me get this straight...

[penguin7of9]

You don't trust Sun, so you're recommending... Microsoft???? Ohh-kayyy..., next post please.

The difference is that with the CLR, I don't have to trust Microsoft: it already is an open standard. That doesn't mean it's risk-free, but it means it's no more risky than many other standards.

All we have for this new IL is Sun's promises to make it an "open" standard. Even without Sun's history on Java, that would be much weaker.

Re:so let me get this straight...

[JohnnyCannuk]

The CLR is not an open standard. It is run by Microsoft. Parts ofr the C# language are open but not everything.

I'll beleive it's open when it can run on Linux, Solaris, *BSD, VMS, OS/390, QNX etc.

Until then a window's only runtime is definitely not an open standard.

And if it is no more risk than the others, I'll stick with the one that does run on all those paltforms...

Re:so let me get this straight...

[penguin7of9]

The CLR is not an open standard. It is run by Microsoft. Parts ofr the C# language are open but not everything.

The entire C# language and runtime are standardized as ECMA documents. The standardization process is run by ECMA, not Microsoft. The intellectual property rules for ECMA standards are defined by ECMA and are clear.

Until then a window's only runtime is definitely not an open standard.

ECMA C# is a standard; a standard is a document--it doesn't run on anything nor will it ever run on anything. Implementations of ECMA C# may run on many platforms; they already run on Linux, OS X, and Windows (perhaps others).

And if it is no more risk than the others, I'll stick with the one that does run on all those paltforms...

If by "the one" you mean "Java", you are going the wrong direction. Unlike C#, Java really does not have an open standard. The Java specifications are not freely redistributable or open and the Java standardization is run by a private consortium rather than a recognized standards body.

You may not like that ECMA C# came from Microsoft. But the legal and political situation surrounding Sun Java is worse in pretty much every respect. If you worry about C# you have to worry about Java even more.

Re:so let me get this straight...

[UU7]

Glad you go by technical merit...

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

Sun is correct to ignore Microsoft's IL

[Kunta Kinte]

That is right on the money. Sun is trying to make an alternative to the CLR - a blantant attempt to take back developers who've switched from Sun J2EE to MS .Net.

And this is wrong... how???

The Mono project and DotGNU project both have plans for compiling Java to IL, allowing .Net and Java apps to talk to each other natively

Mono guys seem to have a lot of plans.

why then is Sun developing yet another IL standard?

How many times does a company have to be convicted of anti-trust behavior before one stops trusting them? Would you, as a Microsoft competitor, bank your new and emerging technologies on standards that Microsoft has copyrights and patents on? Some you've been in court with on many occasions?

Microsoft has said linux is one of their biggest treats. Don't you think they will use those patents and copyrights to hold down open source if given half the chance?

Re:Sun is correct to ignore Microsoft's IL

[penguin7of9]

And this is wrong... how???

It's not "wrong" for Sun to do this. But neither is anybody obligated to use it or support Sun in this effort. Given Sun's history with Java, any open source developer supporting Sun in this effort would be a fool in my opinion.

Mono guys seem to have a lot of plans.

Yes, and they are delivering. Eclipse, for example, already runs under Mono. The Mono project seems technically far more effective and quick than Sun's Java platfom team.

How many times does a company have to be convicted of anti-trust behavior before one stops trusting them?

I wouldn't trust Microsoft and I'm not asking anybody else to trust Microsoft. We don't have to trust Microsoft on the CLR because it's an ECMA standard. That doesn't make the CLR completely risk-free--Microsoft or anybody else might still claim patents even if that violates their ECMA agreements--but it reduces the risk to that of any other open standard; there is no a priori reason to assume that C# or the CLR are encumbered by anything.

Furthermore, Microsoft's violations are anti-trust violations, not lies related to standardization. Sun misdeeds, on the other hand, are directly relevant: Sun claimed they would put Java through a standardization process and then pulled out, twice. That means we won't have to guess about whether Sun is capable or willing to lie about whether a project they do will become a public, open standard: they have already lied about it once.

Would you, as a Microsoft competitor, bank your new and emerging technologies on standards that Microsoft has copyrights and patents on?

Microsoft claims a patent on the .NET APIs as a whole. But what "copyrights and patents" does Microsoft have on ECMA C#/CLR? You can get the ECMA C#/CLR standards from ECMA with no strings from Microsoft.

On the other hand, you cannot obtain Java specifications without agreeing to licensing agreements with Sun or the JCP organization, and Sun claims both copyrights and patents on even core aspects of Java, including the JVM. And we don't have to guess what Sun will do because they have already done it: they claimed they would make Java an open standard and then they withdrew not from one, but from two standardization processes.

XML? This sounds like MetaL

[mlemos]

MetaL

Sounds like Perl 6 / Parrot ?

[AWetDuck]

The Perl 6 developers are working on just such a framework to underly the next Perl.
For anyone who hasn't checked it out yet, this is really cool stuff.

http://dev.perl.org/perl6
http://www.parrotcode.org

Performance

[NitsujTPU]

Maybe now I won't have to write my neural network in C for performance

I wonder if the format will be in XML

Eh?
So it will be high performace, and in XML?

**Looks at you funny**

Is that a good example?

[Kjella]

Most visible in games. Things like Morrowind, where crossing the map without stop takes a hour or more, and exploring all the corners is months of play, were plainly impossible when it all required hand-coding. Now for a developer it takes shorter to create a mountain in game than for a player to climb it. Of course the player needs better CPU to be able to display the mountain which wasn't hand-optimised, just created in an artificial high-level language defining the game world, but if you're going to enjoy the experience - why not?

Actually, I thought stuff like real-time 3D gfx engines were quite heavily optimized. I'd think the places you don't really care are
a) The difference between 0,01 second and 0,000001 seconds.
b) The difference between a 5 minute coffee break and a 6 minute coffee break.
If that mountain is lagging on your (mediocre) hardware, there's a problem. But in more "serious" calculations, only the answer matters. Will there be sun or overcast today? Which investment project is the most profitable? How do I optimally stack these boxes?

Kjella

Re:Is that a good example?

[SharpFang]

I'm not quite sure what's your point (though you sound wise and are probably right)

Thing is, with modern hardware you can afford two things:
1) Sloppy programming. Perform the same task you did 10 years ago in the same time as 10 years ago, but write it in 5 minutes in Perl instead of in a week in ASM.
2) Really good performance. And in serious applications it's often a serious difference between 5 and 6 minute coffee break (1 minute before the competition), and -especially- between 0,01s and 0,000001s. Is this project profitable? Instead of analysing 50 available pros and cons that take 0,01 s on old hardware and 0,000001s on new, you feed the new hardware with database of a billion past similar cases, get a 5-min coffee break and get a much more reliable answer. On old hardware this would take a week and simple analysis had to suffice.

And concerning games... 3D is where -lack- of optimisation shows through most. If your GUI draws for 0.5s because of sloppy programming, it's ok, but if you get 2FPS in a game, it sucks. And despite well optimised engine, a nice curved door with 300 polygons will mean some load and corridor of them - a real challenge to every GFX card. But this is where we allow the designer to place that corridor of doors, assuming "Good hardware will handle that" and continue to build another section of land instead of worrying about reducing the number of polygons or optimising the game engine.

It's fucked already.

[His name cannot be s]

According to the article:

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's expertise in Java? From the asshats who brought us SWING??!?

Thiis is kinda like having Osama bin Laden in charge of bringing peace to the middle east.

Mi parolas la CLR

[michaelnz]

Why do we need a new language when we've already got esperanto?

Cache coherency and JIT

[dido]

The only problem with just in time compilation is that it takes up a LOT of memory. Granted, memory is getting cheaper and cheaper these days, but instruction cache memory is not. Today's cache-sensitive architectures will probably operate at suboptimal rates with a JIT that's generating code on one hand and executing the generated code on the other. That would eventually result in thrashing no matter how big your cache happens to be, and cache misses tend to be expensive in the grand scheme of things if they happen often enough.

In fact, some people have argued (e.g. an article in the August 1992 edition of DDJ, "Personal Supercomputing", by Ian Hirschsohn) that modern RISC architectures shouldn't be fed raw machine code directly at all. Actually a RISC is nothing but a CISC processor minus the microcode; instead it can be "microprogrammed" by placing instructions that live on its i-cache. Paradoxically, interpreted languages might actually be faster than compiled languages on such an architecture! A proper memory-transfer based intermediate language interpreted by a small, hand-optimized interpreter that makes maximal use of the microprocessor's bus bandwidth and is small enough to more or less fit inside the i-cache may well blow any straight or JIT-compiled language out of the water performance-wise on the applications that really matter.

The Java Virtual Machine doesn't fit this description, not by a long shot. Its stack based architecture makes it not terribly efficient in its use of CPU bus bandwidth, and its sheer size alone says that it wasn't designed with platform efficiency in mind. Same thing goes for the .NET CLR, it would seem. This is however the system that was used on the CDC 6600, which was one of Seymour Cray's seminal supercomputer designs (back when his company was known as Control Data Corporation), so perhaps they'll use some of these same ideas.

Re:Cache coherency and JIT

[greenrd]

Today's cache-sensitive architectures will probably operate at suboptimal rates with a JIT that's generating code on one hand and executing the generated code on the other.

Uhhh, I think you're missing one very important point. In a typical server environment, the rate of new code input to the system per minute will be probably quite small. JITs are not supposed to hog like 50% of the CPU time compiling code - they're supposed to take up a minute fraction of the total execution time of a process. So the overall impact should be minimal.

And yes, compiling may be slow. But compiling has always been slow! Time-shifting it is not going to help!

Unless you're repeatedly stopping and starting a Java process - which is a well-known way to get poor performance, for a number of reasons.

Re:Cache coherency and JIT

[tricorn]

I have some numbers (coincidentally, using the CDC 6600 mentioned above). Environment is an Alpha system running (30 year old) Cyber code in a production environment. For much of the code, it has been (statically) translated to Alpha native instructions (although the Cyber architecture pretty much requires straight emulations, as code is often self-modifying, including instruction returns). The translated code runs 5-10 times faster than the emulated code. The emulator is very tight, and straight emulation runs about 20 times faster on recent Alpha processors than they did on a Cyber 830.

Incidentally, "code bloat" factor (ratio of Alpha code to original Cyber code) is around 5 (much of it due to handling the difference between 64-bit 2's complement and 60-bit 1's complement). In the other direction, no-op instructions (of various types) are optimized out. Floating point and population count instructions are the only ones that make a subroutine call from translated code (and floating point doesn't use native floating point at all, except using non-portable kludges for normalization).

Needs no introduction??

[Mulletproof]

"Sun is inviting Cray (of supercomputer fame) and IBM (needs no introduction) to join..."

Wait-- this is Slashdot, right? News for nerds, remember??? Since when did Cray need an introduction?

XML

[samantha]

If this lineup comes up with a computer language, intermediate or not, that is based on a hiearchical mark-up language for data only then I will probably decide there is no intelligent life on earth. Poor XML has a difficult enough time handling simple data that is non-hierachical. I could just see the stripped down mess an XML rendition of a HL would be.

A blatent copy?

[grahamsz]

Whilst i have no counter evidence, it seems unlikely that they'd be creating a copy of CIL.

Optimising high performance code distributed code has a different set of challenges to optimizing desktop or web applications. OGSA already provides a framework for grid applications to exist and communicatate in, and I suspect this already has some overlap with CIL.

About time.

[AnotherBlackHat]

I was begining to wonder if the pcode code concept was ever going to catch on - it's what, 35 years old now?

-- this is not a .sig

Rethinking IL

[kurt_cagle]

The VB.NET implementation illustrates one of the central problems that low level IL seems to be subject to, as alluded to by the previous post. VB.NET is not Visual Basic, requiring a much higher degree of abstraction that many non-tech people (who generally make up the VB audience) find bewildering and cumbersome. It has the form that it has because the language had to be modified in order to work with the underlying .NET CLR, which eliminated many of the inherent advantages of VB in certain circumstances. This can be seen even more with the .NET versions of Perl, which has to sacrifice the highly flexible structure and run-time code construction in order to fit within the constraints of the IL (ditto for Javascript and other "interpreted" languages).

I suspect that the final IL will be XML based, though the encodings will likely be Post Schema Validated Infosets (PSVI) for performance. The idea that you can write a compiler in XSLT is perverse, but nonetheless really, really cool.

Re:Rethinking IL

[Darby]

The idea that you can write a compiler in XSLT is perverse, but nonetheless really, really cool.

How the heck can you do that?!? XSLT doesn't even have variables.

Wrong!!

[kurt_cagle]

Aarggh -- if you're going to doing this, do it right:

Oh god

[mcc]

So now it's considered a defeat or a "retreat" to create a new and improved version of one of your products?

Hey, I heard that Microsoft just released a new version of their OS and called it "Longhorn". cn I say "Ok, so now that WinXP is on the retreat they try to enter a new area?"

Personally, I would consider "Hm, Microsoft seems to be catching up to us. Let's make something better than current Java OR .net." to be the most extreme sign of life possible. Honestly I wish they'd done it sooner.

Re:Not unreadable XML ()

[kurt_cagle]

In all honesty, the XML would be generated at a level where hands would likely never touch it, more likely through a series of transformations. Having written XML generators for C++, C# and Java, I've found that the XML is, by itself, very verbose, because it is fundamentally a meta-level description. You wouldn't write:

<func optargn="burp">arg1 arg2 arg3 lst</func>

you'd write

<function name="foo">
<param name="arg1" type="xs:string"/>
<param name="arg2" type="xs:integer"/>
<param name="arg3" type="cplxOpj"/>
<param name="arg4" type="xs:string" optional="yes"/>
<!-- implementation code -->
</function>

In all likelihood, the fragment will have been generated via a UML interface or something similar, and this would then be produced through a simple transformation.

Before objecting to the cost involved, consider that both an XML parser and an XSLT transformation are fairly straightforward finite state machines, and could very easily be dropped into firmware (something that is already beginning to happen). Because of the ubiquity of XML, firmware processing of XML is making more and more sense, and once you have that, it becomes a natural for building ILs and related compiler technology.

Massive parallelism that doesn't suck is hard

[Animats]

This is yet another attempt to breathe life into the boondoggle of massively parallel architectures.

Over the last few decades, there have been many exotic parallel architectures. Dataflow machines, connection machines, vector machines, hypercubes, associative memory machines (remember LINDA?), perfect shuffle machines, random-interconnect machines, networked memory machines, and partially-shared-memory machines have all come and gone. Some have come and gone more than once. None has been successful enough to sell commercially in quantity. Very few of these machines have ever been purchased by any non-government entity.

There are two ends of the parallelism spectrum - the shared-memory symmetrical multiprocessor, where all memory is shared, and the networked cluster, where no memory is shared. Both are successful and widely used. Everything in between has been a flop.

Despite decades of failure, people keep coming up with new bad ways to hook CPUs together, and getting government agencies to fund them. It's more a pork program than a way to get real work done.

By the time one of these big wierdo machines is built, debugged, and programmed, it's outdated. A few years later, people are getting the same job done on desktops. Look at chess. In 1997, it took Deep Blue to beat Kasparov. Kasparov is now losing games to a desktop four-processor IA-32 machine.

Figuring out more effective ways to use clusters is far more cost effective than putting a National Supercomputer Center in some Congressman's district in Outer Nowhere. There's a whole chain of these tax-funded "National Supercomputer Centers". The "Alabama Supercomputer Center" has ended up as an ISP for the public school system, hosting E-mail accounts and such. It's all pork.

Re:Massive parallelism that doesn't suck is hard

[man_ls]

What kind of desktop machine uses 4-way SMP?

I'm thinking more departmental server or something there.

Re:Massive parallelism that doesn't suck is hard

[Animats]

Buy Deep Fritz 8 now for only $96.95! Get trounced. Runs on 1 to 8 CPU IA-32 machines. It beat Gary Kasparov running on a 4-CPU 2.8GHz Xeon machine. The machine used for that game was in rackmount packaging, but it fit on a tabletop. You can buy workstations with an equivalent configuration.

Dial-up

[tepples]

granted there is the 20 meg framework package, but really thats nothing these days

Tell that to somebody whose relatives live in an area where nobody offers high-speed Internet access for under $60 per month.

Re:Dial-up

[ColaMan]

Tell that to somebody whose relatives live in an area where nobody offers high-speed Internet access, full stop.

Oh look! a 9600bps satellite modem! What fun!
Not.

Re:Dial-up

[JeanBaptiste]

"Tell that to somebody whose relatives live in an area where nobody offers high-speed Internet access for under $60 per month."

Okay, I do all the time. I have an external USB CD burner I bought for 100 dollars. I burn that 20 meg framework (which is a lot less than most MS service packs, I might add) onto a CD. Along with anti-virus and anti-spyware software, among other things.

even if they have no modem access, CDs are cheap, and so is shipping them.

Possible English confusion

[devphil]

All good compilers use at least one intermediate language.

You're thinking the same thing I thought. As a compiler geek, when I hear "intermediate language," I think of exactly this same thing, a temporary representation of the code for checking and/or optimization purposes.

The more I thought about the (poorly-written) article, the more I think that perhaps they mean a new assembly language. Which from a viewpoint of the compiler, especially one like GCC, is not an intermediate language, but the final product. (Some compilers compile directly to machine code, essentially being both the compiler and the assembler, but those are often not portable/retargetable.

I posted about this earlier, but haven't seen a followup yet: which of these two is being proposed? Dunno yet.

Re:Possible English confusion

[iabervon]

I suspect that they want to have the compiler finish with the intermediate language. That doesn't means that another piece of software won't start with the intermediate language and generate native code, however. The point of it being an intermediate language (instead of a common machine code) is that the file contains enough information to then do further platform-specific optimizations. Java bytecode is, in fact, this way, with the issue that, when it was first released, nobody had any clue how to deal with it effectively, because stack machines have long been out of fashion as hardware designs, and bytecodes hadn't been used for anything heavy-duty. Nowadays, Java bytecodes are a perfectly good intermediate language to write a back-end for, except that they're full of Java-specific opcodes.

Re:Parrot is not even close to what they want

[ajs]

Wow, that's a lot of venom for so little fact... Let's disarm a bit of that:

Threading in parrot is still being worked out, but I think what you are looking at is the model being used by the Perl 5 project (currently Parrots biggest customer, along with Perl 6) and assuming that that model is "Parrot's" rather than "Perl's". Perl 5 NEEDS that threading model in order to have the same threading semantics on Parrot as it did stand-alone. Other languages will use threading differently, and Parrot will need to support those models.

Your definition of a "scripting" language is moot. Java is no more or less a "scripting" language than Python. C# no more or less than Ruby. There are several things that make a language what it is:

* basic calculation capabilities (turing completeness)
* how code is dealt with (or not) at runtime (eval, closures, code as data, etc.)
* support for programming models (e.g. OO features)
* syntax and grammar
* level of semantic complexity
* level of hardware abstraction

Modern high-level languages offer a certain take on these features. Perl, for example offers most of the above features with maximal semantic complexity and hardware abstraction. LISP on the other hand offers most of thse features as well, while remaining semantically very regular and simple. Java lies somewhere in between, but its support for features like treating code as data are strictly limited by design.

These are choices, and there is nothing wrong with any of them. To introduce "scripting" as a pejorative term is meaningless. Ultimately scripting refers to the wrote execution of a set of primative commands. In a sense any language with logic structures can be said to have gone beyond this primative stage of "language" design. Also by that same logic you could say that EVERY language meets these criteria. After all, hardware instructions are just primative commands which your program executes in a predictable way.

Lets talk about real language features, not this psuedo-distinction which is used to dismiss languages with more peasant roots than those you might prefer.

You also bring up C... lest we forget, C is one of the thinnest layers on top of assembly that you
can create. Making a byte-code interpreter that doesn't slow down your average C code is called "writing a compiler". Your bytecode would have to be something like GCC's RTL, and that would not give you the abstraction that makes VMs valuable in the first place. C is the language you use when you want to write machine code, but you need to remain fairly portable. No C#, Java or other VM will be able to aproach the efficiency of hand-coding in C until the compiler is able to understand the code well enough to have written it in the first place. That does not make the goal of a high-performance VM moot, it simply sets the upper bound for the limit function.

Not enough

[12357bd]

Think big please. Hundreds of thousands of threads, is not enough, we need millions, thousads of millions of threads.

The only way to get to this level is changing hardware. Current computers, are big memory pools with a single (logical) execution unit, that's the fault.

We need to build thousands of simpler executions units, and parallelization will be a real issue. Switching threads/process is not the answer.

On the software front, two musts for a new languaje: a) it should be 'aspect oriented' (flexible interception). b) automatic paralelization extracted at compile time from objects sets analisys.

Next sig please..

Re:Not enough

[AaronGTurner]

Millions of threads are only
worthwhile if the algorithm
is sufficiently parallel. With
medium level languages such
as C it is easy to create code
that obscures the parallelism.
Thus a new technical computing
language could have a role.

Even if the algorithm is
parallel it may not scale
well under all architectures.
Communication between
elements can be a killer which
is why shared memory
machines are useful as the
architecture for SMP also makes
for a fast communication
system (lf an expensive one)

What you seem to be
suggesting is something best
served by risc, communication
channels from large SMP
machines and better
languages and compilers, plus
SMP functionality for critical
sections

Its a fair amount of work.

JAVA vs. .NET

[digitaltraveller]

Putting corporate politics aside, what would be nice from a technical perspective is an intermediate language that is register-based. Microsoft decided to copy java so thoroughly they also copied java's mistakes by making the .NET runtime a stack machine. Market reality tells us Intel/AMD is not going away anytime soon, it would have been wise to make MSIL fit more nicely into the x86 architecture for performance purposes.

The mono/.DOTGNU projects are similarly unfathomable. It will be nice to have these tools available to run more bloated GUI's, but if one of these projects really wanted to differentiate itself, that project should instead focus on a C# to native-compiler using gcc's backend and let the other project focus on a compiler-to-MSIL. I guarantee you that project would become the 'winner'.

Re:JAVA vs. .NET

[Anonymous Coward]

I doubt that's a significant problem. Remember you're only talking about the structure of the intermediate language here - it's quite possible to do JIT compilation from a stack based lanuage to a register based machine.

All you need is a compiler clever enough to substitute the use of registers for the most frequently manipulated stack locations in a given code fragment. Java and .NET are both capable of doing this. IANAJCW (JIT Compiler Writer) but I believe that stack based languages are in general a pretty good format for compilers to work with.

Register based langages are more complex - especially if the number of registers in your intermediate langauage does not match your target hardware. You'd probably want to convert to some other intermediate format (maybe stack based?) so that you could make sense of the register allocations.

Re:Parrot is not even close to what they want

[Haeleth]

Your definition of a "scripting" language is moot. Java is no more or less a "scripting" language than Python. C# no more or less than Ruby.

Slightly OT: the definition I was taught is that a language is a scripting language if its runtime reads source code directly, an interpreted language if its runtime reads bytecode (like Java), and a compiled language if it generates native code.

This is still not really satisfactory, and it breaks down very quickly when it encounters a language like O'Caml, which supports all three execution models directly, but as a working definition it's not so bad. Note in particular the lack of any pejorative subtext to the "scripting language" definition.

Re:Parrot is not even close to what they want

[penguin7of9]

Your definition of a "scripting" language is moot. Java is no more or less a "scripting" language than Python. C# no more or less than Ruby.

Java and C# are statically typed languages, designed to allow type-safe, efficient separate compilation. Python is a dynamically typed language with a flexible but inefficient object model. Sometimes, the distinctions between scripting and non-scripting programming languages are blurry, but in the case of Java and Python, there is little question which is which.

You also bring up C... lest we forget, C is one of the thinnest layers on top of assembly that you
can create.

That may have been true for the PDP-11 and K&R C, it is wrong for modern machines and ANSI C: ANSI C semantics and machine semantics have become very different.

Lets talk about real language features, not this psuedo-distinction which is used to dismiss languages with more peasant roots than those you might prefer.

Yes, let's: Parrot is designed for the execution of dynamically typed code with a highly dynamic object model. Parrot seems to have no features to indicate properties like absence of aliasing, vectorization, detailed control of floating point computations, or value classes. Parrot will be a nice VM for many applications, but high performance numerical computing doesn't look like it's going to be one of them (at least not in the Fortran sense; of course, Parrot will be suitable for Matlab-like scripting and interaction).

Re:Parrot is not even close to what they want

[NickFitz]

a language is a scripting language if its runtime reads source code directly, an interpreted language if its runtime reads bytecode (like Java), and a compiled language if it generates native code

Hmm... JavaScript is a scripting language which is compiled into bytecode (both Netscape/Mozilla and Microsoft implementations do this). JScript.NET is compiled into CLR bytecode which is then JIT compiled into native code. In principle, any JavaScript implementation could do this (although I don't think Mozilla does, yet). So is it a scripting language, an interpreted language, or a compiled language?

Not flaming, just thought it was something to brood on...

juice

[cmonster]

I hope they look into juice rather then doing yet another stack machine. Supposedly by using a tree structure as its intermediate rather then byte code more of the original intent of the program is preserved allowing for more powerful optimizations to be done by the jit.

Just one more reason to Free Java

[roman_mir]

I posted this before, but it looks to me that this is still on topic here. How about making Java Free, openning it to new possibilities, optimizations etc.
----------
I would like to see GNU/Linux to become a more powerful platform and by a more powerful platform I mean a platform that provides the user with a pleasant experience. Now, to provide a pleasant experience a platform must give the user a choice - a choice of applications that exist for the platform is a step in the right direction. However, GNU/Linux is not such a platform yet. If it were, it would have been embraced by the masses already and it is not. There are a few things that GNU/Linux system is lacking and one of the more important lacking components is a convenient tool that allows a novice create his/her own software for the platform, software that easily manipulates data imported from multiple sources and allows to create graphical interfaces to that data. In the Microsoft this functionality is provided by such a ubiquitous tool as Visual Basic. In the Free Software world there are many tools that are extremely powerful but none of them have the same kind of momentum that Visual Basic delivers on Microsoft platform.

To answer the question- "What can be the VB for Free Software?" we need to look at the kind of problems that will have to be solved by this tool. The problems solved by VB are of many kinds, but for the general public VB provides the bridge that closes the gap between a user and a multitude of small problems that the user wants to solve. Of-course it is possible to just create a VB IDE for FS platforms but I believe there is a more interesting solution to this problem and it is Java. Just like VB, Java runs in a virtual machine, so the user will never really have direct access to any hardware resources, but an abstract layer of JVM can provide a nice buffer between the user and the hardware and at the same time Java will always behave in the same way on multiple other platforms, including Windows. Java has thousands of convenience libraries, there is enough Free Software written for Java that can be integrated into an IDE. However there is a big problem with the language itself - it is not Free.

Sun allows anyone to use Java for free but nobody can modify the language itself except for Sun. In order for Java to become for Free Software and Gnu/Linux what VB became for Microsoft, Java has to be Freed and put out under the GPL. There is also probably a good business sense in it for the Sun Microsystems as well - their language suddenly becomes the language of choice for millions and thousands will work on improving the language, the virtual machine, the compiler etc. In this case Sun will stay in a position that Linus finds himself in - they become the gate-keepers for the vanilla Java tree, but Java will branch and will become much more spread than it is right now. Sun can capitalize on that by providing more Java based solutions and services.

Now it is likely that Sun management will not agree to the change of their Java's status, however, if there was an immediately profitable reason for them to do this, they just may turn around and start thinking about it. A reason that is profitable could be a large sum of cash available to them upon releasing Java under the GPL. Where could this money come from? These money could be collected by the FS and OS supporters, the developers and the users who would like to see more momentum in the GNU/Linux movement towards a successful (wide spread) desktop solution. I suppose no one will seriously object to have one more powerful tool in their Free Software tool-bag. Java can be this tool and it can be just the thing needed to tip the scales over towards quick appearance of a useful and a popular GNU/Linux desktop.

Re:Just one more reason to Free Java

[elflord]

Sun allows anyone to use Java for free but nobody can modify the language itself except for Sun. In order for Java to become for Free Software and Gnu/Linux what VB became for Microsoft, Java has to be Freed and put out under the GPL.

First, you've made the mistake of confusing the language with an implementation of the language. These are different things entirely. I'm not even sure what it would mean for the language itself to be "free". Maybe if it were submitted to a truly open standards group (like ANSI/ISO C and C++) that would make it more "free" but I don't see how that would help. Of course having a good free implementation of the language is important, but that doesn't mean that Sun needs to provide that implementation. gcc is not provided by the original implementors.

Of course there are free software implementations of java.

As for releasing java under the GPL -- I don't see it happening. Releasing it under an appropriate open source license would help Suns implementation become more popular, but they wouldn't be able to make money licensing their source code.

Re:Next try?

[kingkade]

If you look at the link I posted (on the first line, no less) you'd have seen:

Welcome to JavaDesktop, a new gathering place for members of the Java graphical user interface (GUI) community.

So it obviously has nothing to do with the "JavaDesktop" of which you only know of through whatever is in the summaries on Slashdot. I know you were anxious to post something, but you've made yourself look like a jackass.

Re:With the only penalty being "hello world" is 7

[RetroGeek]

Private Sub Form1_Load(

Excellent naming of your forms and variables!

Pure gibberish

[Ars-Fartsica]

A little knowledge is a dangerous thing. There is a reason that we apply and peel off abstactions at different layers of the system. And no there is no need for reflection at the assembly level.

Re:Parrot is not even close to what they want

[Sri Lumpa]

I have to disagree with that definition given that before the current craze with virtual machines an interpreted language (or interpreted mode for multi-modes languages) was a language whose program's source code was given to an interpreter (like Lisp or Basic) and so matches your definition of Scripting. Also just in what way is the bytecode interpreted? Translated from bytecode to machine code, yes, but interpreted?

As for a scripting language, it was mostly used for languages in which you were supposed to glue programs and create small utilities that way (like a shell script) but didn't even think of the possibility of writing a full-blown application using them.

However with the advent of Perl and Python which are considered scripting languages yet have enough power to write fairly complicated applications the boundaries between scripting and full-blown programming languages is fading.

Of course they were not the first to do that, you noted OCaml but almost any functional programming language would have done as an example, especially Lisp due to its anciant roots (the first Lisp was defined in 1958, making it one of the oldest family of languages still in use today) and the fact that it is generally interpreted at development time and compiled (either to bytecode or to machine code) when development is finished (or at least, when you start profiling and optimising your program).

It is Perl's nad Python's popularity that forced mainstream computing to ask themselves these questions but they are nothing new or important, they are just artificial distinctions fulfilling our innate need to put things in categories even if they are too complex and don't fit.

Who is jumping on whose bandwagon?

[John Harrison]

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 :-))

IBM has been doing work on this stuff for a while now. This is part of the point of the "on demand computing" initiative and is also related to "grid computing". If you can run your job on ANY computer then computing becomes more similar to a utility. You don't care/know what machine it runs on or even where it runs. It just gets done.

IBM has invested huge amounts of R&D into this already as well as quite a bit on marketing it.

So Sun's invitation to IBM and other to "join" them might be a way of trying to jump on IBM's bandwagon and benefit from work that IBM has already done. If IBM says no, then those who don't understand what is going on will think that IBM looks bad.

Re:Who is jumping on whose bandwagon?

[fw3]

Yup, I've worked with them on a couple of things and while I didn't bother to state it, I fully expect that IBM's investment and technology are well ahead of Sun on this.

Otoh, an intermediate language may still be a good idea, and the better (from my POV) if it were portable.

Re:Who is jumping on whose bandwagon?

[John Harrison]

Part of my point, which I didn't articulate very well, was that in order for IBM's vision of grid computing and on demand computing to work, it seems that there needs to be an intermediate language. I would guess that much work has already been done on this. There also needs to be a lot of infrastructure to allow jobs to get passed around.

Bray-ve new world

[leonbrooks]

I know you were anxious to post something, but you've made yourself look like a jackass.

"Ah, well, since the knife is in anyway, I may as well twist it"? (-:

They've had, what, 30 or 40 years...

[leonbrooks]

...to make P-as-in-Pascal code run like lightning? And it ain't happened yet. It's struggling to run, like, today.

The Professor Jeff S Rohl not mentioned in most of the Pascal articles (possibly because he's more famous for Modula2 etc) lives about 20km south of here.

XML with Hollerith codes?

[leonbrooks]

Yumm-mee!

IRL: exit stage left, screaming. (-:

You left one keyword out.

[leonbrooks]

VB has the edit/compile/debug cycle all in one interface.

You forgot to mention that alongside the debugger, it has quite a bit of bugger factor built in. For example, only the very latest rendition of it can be construed to be OO. So that makes it an edit/bugger/compile/debug cycle.

The language is not the IDE. Tried KDevelop, GLADE, IDLE, Boa Constructor or any of the other FOSS IDEs recently?

Or, for that matter, Blender? (-:

Re:You left one keyword out.

[Uzik2]

The one thing I really liked about that ide was the integration of the help files and debugger. You could hover the cursor over a string and see the value of that variable or as you typed a function name it would give you a prompt showing the order, type, and function of each of the parameters. Which would you recommend? KDevelop, GLADE, IDLE, or Boa Constructor?

I thought blender was a 3d graphics program?
I already use 3ds max. ;)

Re:You left one keyword out.

[leonbrooks]

I'd recommend a very recent KDevelop with all of the fruit.

Blender can spit out programmed demos (-: read: "games" :-) so it counts as an IDE.

Re:You left one keyword out.

[Uzik2]

Thanks! I'll take a look at it. I guess
blender is turning into gmax or game developers
studio?

I can cut that down to 21 bytes and 660kB runtime

[leonbrooks]

Bonus genuine OO, wide portability, non-onerous licence terms and all manner of other bells and whistles:

echo 'print "hello world\n"' >hello.rb

Self-executing version bloats this to 37 bytes:

echo '#!/usr/bin/ruby' > hello.rb
echo 'print "hello world\n"' >> hello.rb

If you want that in a messageBox, you need to ramp it up to 153 bytes and add about one more meg of runtime. If you want it in 3D, add another 60kB of runtime, deeming OpenGL included.

So did I win this dick-shrinkage competition? (-:

That and having to K)runch your drives regularly

[leonbrooks]

The disk structure was very Forth. Can you imagine having to K)runch one of today's 300GB monsters every night?

Re:Parrot is not even close to what they want

[ajs]

Java and C# are statically typed languages, designed to allow type-safe, efficient separate compilation. Python is a dynamically typed language with a flexible but inefficient object model. Sometimes, the distinctions between scripting and non-scripting programming languages are blurry, but in the case of Java and Python, there is little question which is which.

Most of your list of comparisons are correct. The rest are conclusions based on perspective (e.g. efficient vs. inefficient, which are subjective terms that you clearly have some notions about in this case). I'll grant that those are somewhat fair comparisons. However, you again try to shoehorn in the word "scripting". This is a semantically null word which you seem to think means "lesser".

The more apt term (and one that has been in use for quite some time) is very high level language (VHLL). A VHLL will tend to be one which abstracts hardware features, usually at the cost of performance, in order to simplify large programming tasks.

That may have been true for the PDP-11 and K&R C, it is wrong for modern machines and ANSI C: ANSI C semantics and machine semantics have become very different.

Not really, no. The x86 platform continues to be "your father's CMOS" emulated on top of increasingly more sophisticated designs, and other platforms don't really offer a substantially different programming model (architecture, and execution YES, but those are different things). Such changes as in-core parallelism, speculative execution and virtual register banks don't really have to impact how you think about the hardware. ANSI C really didn't change the language's standing with respect to hardware. ANSI C is no higher level than K&R... the largest changes were in fact around the prototyping and pre-processing models. Certainly ANSI C's impact was mostly in the full definition of a standard C library....

Parrot is designed for the execution of dynamically typed code with a highly dynamic object model

Not really, no. You start thete, and then move down to a level that suits your needs. Perl 5 for example will not need to move beyond what you describe, but Java most certainly will, as will C#, both languages that the Parrot developers are keeping the platform open to.

Parrot seems to have no features to indicate properties like absence of aliasing, vectorization, detailed control of floating point computations, or value classes

Some of these things are there (perhaps to your satisfaction, perhaps not), but again let me stress, that Parrot is an attempt to create an inclusive VM. If these features are needed for such a goal, then they will be added as they are needed. Perhaps you would like to help?

Re:Parrot is not even close to what they want

[ajs]

That definition falls down in the face of most modern high level languages, and most older ones. All LISPs have an eval... how does that play in? Perl compiles to an intermediate representation, optimizes, then executes... that certainly does not match the model of a scripting language like Bash or VMS's shell.

When I hear "scripting language", I think of the batch file systems of yore, and recall what real scripting was. Languages like Ruby, Perl, Python and O'Caml are Very High Level Languages (VHLL), and not scripting languages.

Re:Parrot is not even close to what they want

[ajs]

If you think that, in 2 years you can write a VM that satisfies all of the lanugages that Parrot targets, have at it... I'll use yours if it really is better than Parrot.

It's a HUGE job, and realistically, if they do it right, one that can never truly be done (because new models of language design require growth and adaptation). I'm just glad that someone is doing it.

Too bad they pissed away $180,000 in Perl Foundation money and have nothing to show for it

Your points fall apart into baseless attacks here. Go back and look at what Parrot DOES have to show... I've only written a little Parrot code, but it has worked very well for my attempts to code some Perl primatives and for my work with the Python front-end (which is still fairly primative).

This is hard work, and I encourage you to help if you feel it's too slow.

Re:I can cut that down to 21 bytes and 660kB runti

[JeanBaptiste]

thats great. really. but will it run on windows?

all the stuff I have to deal with has to run on windows, as well as access SQL databases, and things of that nature.

Show me how to do a SQL query in ruby, and then I will be impressed.

but sure, your hello world is slightly smaller than the first one I wrote on a 286 with borland C. congrats to you.

XML & OOP

[hayriye]

OOP based and XML format bytecode for supercomputers and it is equivalent to what kripton is for Superman

Yes, it will run on MS-Windows

[leonbrooks]

I understand that the runtime is slightly larger, and I'm not sure about the gtk/GL stuff, but Ruby in general is highly portable.

Re:Total nonsense

[Art Pollard]

Well, it is simple. They have not only come out with a .NET framework which admittedly, is similar to the Java stuff but, they have also adapted a whole slew of languages to use it. I have yet to see gcc C++ output to JVM byte code. Sure, there are some languages that compile to JVM bytecode but not many highly used ones (except perhaps Python/Jython).

What Microsoft brings to the table is not only .NET but a host of languages to take advantage of it. Not only that but they do it (more or less) in the same distribution (Visual Studio) and finally, they have the type systems interoperate. What the Java community needs to do is to get gcc and other languages/compilers that are available to compile not only to native but also to JVM bytecode and have the languages's type systems interoperate in such a way that linking to libraries from any is as trivial as adding the library to your project.

I'm no fan of Open Source. However, IMHO, the whole underpinning of open source movement is that it is anti-Microsoft and it is trying to abandon Microsoft by competing in a way that Microsoft can not compete. The Microsoft strategy to kill the open source movement (which it will never be able to do entirely) is to "out develop" the open source community. Microsoft has a legion of programmers all dedicated solely to developing libraries and NEW technologies for Longhorn that will make businesses more productive such as including the technologies that they aquired from Great Planes Software directly into the OS/.NET framework. Microsoft's strategy is simply to out develop everybody else.

Up to this point, operating systems have been fairly simple without a whole lot of features. That is why it is possible with a relatively small crew to write one that is fairly good. (It is still a big project don't misunderstand.) However, what Microsoft is planning with Longhorn is to raise the bar almost impossibly high and to make it such that the amount of coding required to offer something similar is almost an impossible task.

Does this mean that the efforts of Sun, IBM, Novell, and the rest of the community to fight Microsoft will fail? No not necessarily. But Microsoft is now fighting for its life and it is not going to go down easily. Microsoft has literally billions of dollars of spare cash it its banks and investments. With these billions of dollars at its immediate disposal, Microsoft's goal (perhaps for the first time) is to offer so much value that it is almost foolish to consider an alternative.

-Art

.sig? What's a .sig?

not the best solution

[distributed]

This IL obviously like many other things cannot be the best solution in all cases.
Which is why there generally are a million ways to solve each of the kazillion problems... each having its own plus points.

Its thus difficult to say that a universal intermediate runtime language for hi perf computing will emerge.
Even the design of a new computing architecture can render it ineffective (unless it is designed to avoid these issues, but then?) though ofcourse this doesnt happen overnight.

On the other hand ppl can even start making architecture specifically optimized for this language widely increasing its popularity. (speculation)>/p>

Look at what transmeta did in the crusoe. Adding another abstraction layer between the vliw cpu and the native x86 code had some very interesting results. As a matter of fact an IL could be even more useful in vliws when this arch gains popularity since optimization at the level of the IL maybe preferred over direct assembly(!) optimization in this case.

so imho this IL is not really going to be anything more than an interesting way to do high perf computing.

happy computing fellow nerds.