Slashdot Mirror

← Back to Stories (view on slashdot.org)

Intel's Open Runtime Platform Specs

Posted by timothy on from the ac-dc dept.

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

7 of 26 comments (clear)

  1. Is this... by 3-State+Bit · · Score: 4, Informative
    ...like Parrot?

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

    I think.

    From elsewhere:
    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?

    1. Re:Is this... by XBL · · Score: 5, Informative

      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.

    2. Re:Is this... by cbiffle · · Score: 5, Informative

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

  2. Article Distilled: by Ayanami+Rei · · Score: 5, Interesting

    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.

    --
    THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
  3. Relative performance to microsoft CLI...? by rhyd · · Score: 4, Interesting

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

    --
    'Be the change you want to see in the world' - Al Gore
  4. Bytecode / microcode by vlad_petric · · Score: 3, Informative
    (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

    --

    The Raven

  5. One thing is always constant by hayriye · · Score: 5, Funny

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