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

26 comments

  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 Anonymous Coward · · Score: 0

      Parrot doesn't do "managed code", does it?

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

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

    4. Re:Is this... by Anonymous Coward · · Score: 0

      hey thanks! +5 informative.

  2. VVM by Jeremiah+Cornelius · · Score: 1, Redundant
    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!

    --
    "Flyin' in just a sweet place,
    Never been known to fail..."
  3. 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
  4. Re:Article Distilled: Phew! by SpaceLifeForm · · Score: 2, Insightful

    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.

    --
    You are being MICROattacked, from various angles, in a SOFT manner.
  5. Interesting by __aafkqj3628 · · Score: 1

    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.

    1. Re:Interesting by Synic · · Score: 1

      uhh
      intel isn't a corporation?

  6. So what does this mean for virtual machines? by the+eric+conspiracy · · Score: 1

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

  7. Portable.net by absurdhero · · Score: 2, Informative

    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.

  8. No Microsoft Involvement by Ayanami+Rei · · Score: 1

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

    --
    THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
  9. machine code Java by Anonymous Coward · · Score: 1, Interesting

    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.

  10. 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
    1. Re:Relative performance to microsoft CLI...? by Anonymous Coward · · Score: 0

      nah, MRE is associated with your ass

    2. Re:Relative performance to microsoft CLI...? by Randolpho · · Score: 1

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

      --
      "Times have not become more violent. They have just become more televised."
      -Marilyn Manson
    3. Re:Relative performance to microsoft CLI...? by Anonymous Coward · · Score: 0

      Microsoft JVM was based on Sun code. CLR is based on third party Java clone that MS purchased.

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

    1. Re:Bytecode / microcode by Anonymous Coward · · Score: 0

      Stack machines are not necessarily inefficient- it's a common myth that they "obviously" can't be parrallelised. In fact, the BOOST project (read the "final paper" PDF, not the html) showed that superscalar stack machines are easy to design, and have comparable performance to register machines, while retaining stack machine's superior interrupt handling and downright simpler and more sensible programming model!

      It's mainly just an accident of history that the register-machine geeks got their superscalar on before the stack-machine geeks. Once you go superscalar, register files are really just optimisation hints to the chip anyway - might as well use the implicit encoding of a stack machine asm, and use up less mem bandwidth...

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

  13. but Porable.NET is GPL by Anonymous Coward · · Score: 0

    Portable.NET is GPL which makes it useless for commercial development. They should have used LGPL or something that allows it easier to make commercial applications with it.

    1. Re:but Porable.NET is GPL by Anonymous Coward · · Score: 1, Informative

      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.

  14. ORP Open? by Anonymous Coward · · Score: 1, Interesting

    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?

    1. Re:ORP Open? by duder · · Score: 1

      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.

  15. Parrot not ready for primetime by Anonymous Coward · · Score: 0

    Parrot won't be ready for Primetime for at least another 3 years. All the bundled languages are incomplete. Parrot has no concept of modules - all its code must exist in a single PBC file. There are no exceptions, the string opcode APIs are being rewritten, there are no OO constructs and the opcodes change every week. Parrot has to do some serious feature removing if it is ever going to work. Its design is just too needlessly complicated and convoluted. 6 stacks, close to 200 "registers", bizarre on-demand loadable op-codes. This is not intended to be a flame, but Parrot in its present state is not usable for any serious work. At least the Intel product actually functions. Parrot does not. Let's compare apples to apples here.