Intel's Open Runtime Platform Specs

prostoalex writes "The new issue of Intel Technology Journal has a lengthy article on a new platform, developed in Intel labs. The Open Runtime Platform: A Flexible High-Performance Managed Runtime Environment describes the platform that is capable of running both Java VM and Microsoft's CLI, on both Windows and Linux platforms. Full PDF version is also available."

Is this...

[3-State Bit]

...like Parrot [parrotcode.org]?

Apparently that already runs several languages, including Python and PHP...C++ and Java are definitely supposed to be supported.

I think.

From elsewhere [everything2.com]:
Since it is a virtual machine executing virtual assembler code, there are several different languages that compile to Parrot bytecode - it isn't limited to Perl! Here are some of the languages that have been so far done to varying degrees:

Jako, a C-like language developed for testing Parrot

Cola, likewise, but more Java-like

BASIC

Forth

...and an extremely rudimentary Perl 6 compiler...

What do we think?

Re:Is this...

[XBL]

No, this article just shows how interfaces creating abstraction can be implemented between the virtual machine, the just-in-time compiler, and the garbage collector without a performance hit.

This level of separation then allows a better implementation of each of these components to be more easily created. For example, a JIT that supports both Java and CLI is more easy to design and implement. No knowledge of the VM (besides the interface) is needed to do this with ORP.

Overall, a very impressive article.

Re:Is this...

[cbiffle]

Nope, not like Parrot, because the JVM and CLI are not like Parrot. There are a lot of differences, but the two main ones are:
-Static typing.
-Stack-based (vs. register-based)

The JVM and CLI are both designed for static-typed languages, like Java, C, C++, C#. Parrot's main deviation from previous VMs is its design around dynamically-typed languages like Perl and Ruby, with the corresponding techniques to make this fast.

Furthermore, the JVM and CLI are both stack-based, while Parrot is register-based. These involve different optimization techniques and a different underlying virtualization.

The framework described in the Intel paper is most definitely static-type oriented (they discuss the difference in casting-exceptions in C# and Java, and how they handle it), and most probably stack-oriented (though that doesn't seem specified).

VVM

[Jeremiah Cornelius]

VIRTUAL virtual machines!

Now, all we have to do is port these to simulated hardware achitectures that exist only in memory - Like a PDP-6 or Mac-512 emulator.

The real value to Intel will be complete!

Article Distilled:

[Ayanami Rei]

We managed to create a virtual machine that is the superset of the .NET CLR and the JVM. This super-vm can compile straight into machine code for IA-32 and Itanium, and it can do it dynamically in realtime through profiling. It also has a bunch of different optimizers and garbage collectors it can pick from.

All this is implemented in C++. They use opensource class libraries to provide the classpaths.

What I would find really cool is if they can release a microcode-based CPU that runs the superset bytecode. It may simply be a microcode patch to the Itanium. That would be truely wicked.

Re:Article Distilled: Phew!

[SpaceLifeForm]

Sorry, but this entire concept has a strange smell to me. Technically it seems cool, but I don't see the appeal of Intel and Microsoft getting in bed together one last time.

No Microsoft Involvement

[Ayanami Rei]

except that it can be built with MSVC for Windows. It has an entirely Linux/BSD toolchain and library set.

machine code Java

[Anonymous Coward]

I would love to see an open source ahead-of-time compiler for Java.

There have been great speed gains with Java, but it still has enormous memory overhead. I would like to see more numeric computation in Java, but I'm not sure it will with the memory requirements Java typically has.

I know that GCC has a Java ahead-of-time compiler in it, but last time I checked, the memory specs were comparable to the JIT/JVM/whatever it is.

Does anyone know about the memory specs on this? I looked through the paper extremely quickly, and didn't see it in there. I assumed the "performance" tables I was looking at was referring to speed.

Bytecode / microcode

[vlad_petric]

(This comment mainly refers to the Java bytecode; AFAIK though most of it is true about CLR, too)

The bytecode, if executed "as is", can be *extremely* inefficient, as the virtual machine is a stack one.

Modern JITs take a completely different approach to achieve decent performance - they reconstruct the control flow/data flow from the bytecode and then "recompile" (with heavy optimizations, that you can't really do in hardware) into native code. Translating bytecode to instructions directly (or naively) gets you very little benefit over interpretation. The problem is that you can't do more than naive translation in hardware in an efficient manner

The bytecode is very high level - so high level that you can reconstruct the sourcecode from it (modulo local var names). Hardware likes simple stuff, and as a consequence it's not good at executing it efficiently

Interesting

[__aafkqj3628]

It looks to be a very intresting platform, but the acceptance rate for these type of advantages that could really help the world is very low and doesn't look like it's going to increase (due to the ignorance of consumers and the iron-claw of business monopolies). Even if it does take off, it will probably be mutated into some sort of corporate-owned POS.

Re:Interesting

[Synic]

uhh
intel isn't a corporation?

So what does this mean for virtual machines?

[the eric conspiracy]

So does this work imply improved performance for JVM's. CLI's and other such virtual macine environments?

Portable.net

[absurdhero]

DotGNU's Portable.net [dotgnu.org] has MS CLI and Java support. It is portable to virtually every platform, as its name implies. Im glad to see more of these next generation virtual machines in the making.

Re:but Porable.NET is GPL

[Anonymous Coward]

Don't confuse commercial with proprietary. There are plenty of commercial GPL products. The de-facto-standard "gnat" ADA compiler used by most of the defense industry, for example.

Relative performance to microsoft CLI...?

[rhyd]

Although the pdf has a pretty comparison graph of performance with Sun's JVM (which intel wins) there is no such analysis of intel's MRTE against microsofts CLR. I dunno but suspect there is gonna be a MS EULA that absolutely forbids publishing benchmark results of the MS CLR. Either that of intel's MRTE was slower! Anyone read the EULA?

The only thing I got from the article was an appreciation of just how much the MS.NET developers copied the Java architecture. It would seem that to achieve the grand unification of CLR and JVM the Intel engineers just had to define a 1-1 mapping between buzzwords ;)

(
gripe: "runtime" is only one word so it should be called MRE... i guess that name was avoided because it is associated with Jim Carey's villan in Batman Forever :)
)

Re:Relative performance to microsoft CLI...?

[Randolpho]

Considering that the CLR evolved almost directly from Microsoft's non-Java compliant Java Virtual Machine, I'm not surprised CLR is very much like a Java VM. ;)

One thing is always constant

[hayriye]

Java: Language is constant, others can vary.
.NET: OS is constant, others can vary.
Portable Runtime: Processor is constant, others can vary.

ORP Open?

[Anonymous Coward]

If ORP is so open as it name implies - Open Runtime Platform, then why is it closed source?

Where can I get a copy of this ORP that they talk about so I can make my own comparisons?

If they did release the source code to ORP, would this compete with Sun's Java JVM and Microsoft's .NET CLR then?

Re:ORP Open?

[duder]

This thing has been around for awhile actually. It is licensed under the Intel Open Source License and you can download it (yes source) from here [sf.net].