6 ms·

Charlie Nutter's Response to "Why Not A Bytecode Vm"

135 points by johnbender 15y ago

kkowalczyk 15y ago
As much as I respect Nutter's achievements and his jvm chops, his response reads like nitpicking based on his misreading/misunderstanding of what Dart guys wrote and what they meant by it. The position of Dart guys is simple: by compiling an arbitrary language (Dart in this case) to x86 (or whatever native arch the browser is running on) they can get a much faster code than compiling to an abstract VM, like JVM or .NET or parrot. It's not a controversial statement: JVM ultimately compiles to x86 too, so whatever optimization tricks JVM does to generate fast code can be used by a compiler that goes directly from source to x86. The opposite, however, is not true: JVM does introduce an additional layer and fixes in stone many things other than just the instruction set that make compilation of some scenarios from jvm to efficient x86 impossible. And you can't fix that without introducing incompatibilities i.e. breaking existing code. One example of this is class format layout: it has known problems, many of which were fixed in Dalvik. Dalvik, not being jvm, can fix them, but jvm can't without fragmenting the platform. Nutter doesn't exactly contradict the fact that targeting x86 directly results in faster code but all his nitpicking is designed to give that impression. For example, because Dart paper mentioned in passing that JRuby can't be made as fast as native Ruby, he tears into that because JRuby is actually close to Ruby 1.8 in performance. Which, of course, proves nothing. The best JavaScript implementation on JVM is on par, performance-wise, with the old, pre-V8 JavaScript interpreters. V8, Nitro, and Mozilla's various Monkeys all beat that 10-20x, easy. Nutter latches to the unfortunate example Dart paper gave but completely ignores other examples that do show that targeting x86 is, indeed, 10-20x win for dynamic languages. When the paper says that jvm lacks features to implement at least some possible language features efficiently (like built-in instructions for tail-calls) and you can't do anything about. Nutter interprets it as some literal "JVM does not let you do what Java cannot do" but instead of addressing the point (lack of certain primitives needed for fast implementation of certain construct) he again use the JRuby-Ruby 1.8 speed parity as somehow showing Dart guys are wrong. In "A bytecode VM is more than just bytecode" he uses turing-machine argument: both jvm and x86 is turing complete therefore they're just as good. He tops with really weird statement like "Compiling to x86 works best if your feature set fits x86" (if your feature set doesn't fit x86, there it doesn't fit anything). He also brings invokedynamic as a pro-JVM argument disregarding the fact that it's a recent addition to JVM that breaks backwards compatibility - you can't run Java program that uses invokedynamic on older JVMs because they don't understand it. I could go on. This post is just nuts. Here's the real kicker: Nutter is the same guy who develops Duby and Mirah, a static Ruby-look-a-likes. Why does he develop Mirah? From http://www.mirah.org/ http://www.mirah.org/: "No performance penalty Because Mirah directly targets the JVM’s type system and JVM bytecode, it performs exactly as well as Java."
- deleted 15y ago
  [deleted]
- extension 15y ago
  The position of Dart guys is simple: by compiling an arbitrary language (Dart in this case) to x86 (or whatever native arch the browser is running on) they can get a much faster code than compiling to an abstract VM, like JVM or .NET or parrot. No, their position is against creating a new VM for the Dart language, and they justify it, in part, by saying it would end up with the same limitations as the JVM. Nutter isn't arguing with this position though, he is just countering their assertions about the JVM.
  - kkowalczyk 15y ago
    Except all his argument are by proxy. Is it not true that "the JVM assumes you want classes, single dispatch, inheritance, and primitives. It assumes you don't need 32-bit unsigned math." ? Is it not true that "adding new bytecodes increases the complexity of VM? That to add "all possible languages a VM needs to support a multitude of calling conventions: tail calls, optional arguments, rest arguments, keyed arguments, overloaded methods, and so on" ? Is it not true that "jvm specifies a class file format, a concurrency model (in the case of the JVM threads with shared state), class initialization, and a bunch of other stuff that nails down semantic choices." ? Those are the actual "assertions" made by Dart paper. Which of those facts about jvm Nutter actually countered?
  - rayiner 15y ago
    > by saying it would end up with the same limitations as the JVM No, they were saying that it would end up with a different set of limitations, and gives the JVM as an example. E.g. if you exposed the current Dart VM's feature set as a byte code VM, ML folks would complain it doesn't support tail calls, Haskell folks would complain it doesn't allow them to efficiently encode their TABLES_NEXT_TO_CODE optimization, etc. Java folks would complain it's integer semantics are wrong (overflow to bignum rather than wrap-around), that it lacks support for arbitrary class loading, etc.
    - 15y ago
jws 15y ago
Sign in and be tracked to read an article? Thank you, no.
- mappu 15y ago
  I'm not signed in, and the server didn't seem to set any cookies.. Here's a plaintext copy: http://cr6nh1.pen.io http://cr6nh1.pen.io (though the formatting might be better suited to pastebin)
- roopeshv 15y ago
  i am not signed it, and I still read the article. I keep hearing this complain all the time with google groups. Is it specific to only few or are they based on assumption that it's a google group?
  - chc 15y ago
    It's a weird bug with Google Groups. As far as I can tell, if you aren't signed into any Google service at the time, it will let you in. But if you are signed into another Google service, Groups will demand you re-authenticate.
- rmc 15y ago
  To counter what others are saying, I was being asked to sign in to view this article. (Though as @chc points out < http://news.ycombinator.com/item?id=3384888 http://news.ycombinator.com/item?id=3384888 > I am signed into another Google property on my work email account, so perhaps that's why it's asking me )
- azylman 15y ago
  Groups doesn't track which articles you read, even if you're signed in.
azylman 15y ago
Let's link to the prettier version of Groups instead of the old, out-dated one... https://groups.google.com/a/dartlang.org/forum/#!topic/misc/u_jk0906sYg https://groups.google.com/a/dartlang.org/forum/#!topic/misc/...
- cemerick 15y ago
  "Let's link to the glam version of Groups instead of the old, usable one..." Fixed that for you.
  - _Y_ 15y ago
    "Let's link to a internally consistent version of Groups that doesn't look like the old familiar one..." Fixed it for you.
azakai 15y ago
The response is right to correct various errors in the original article. But it also misses the point. Yes, JRuby is fast in comparison to other Ruby implementations. But this says nothing, because in general "normal" C and C++ code can be converted to run on the JVM with similar speed to the original: The JVM (the standard one) is very good at that sort of thing. But, there are kinds of code that do not run fast on the JVM. Examples of that are self-modifying code. Ruby implementations happen to not rely heavily on that, so running them on the JVM is fast. However, other dynamic languages that are much faster than Ruby do rely on those techniques, critically so. There has been a lot of effort to bring those advanced techniques to managed runtimes like the JVM, with the goal of running dynamic languages on them quickly. But overall, native implementations are still far faster. For that reason, Microsoft didn't implement a new JS engine on .NET, it wrote a native one, and for the same reason Google is developing a new Dart VM instead of reusing an existing VM (although, that isn't completely true because Dart also compiles to JavaScript, so it can reuse existing VMs, presumably efficiently because the language design clearly shows signs of being optimized to run fast when compiled to JS).

135 points by johnbender 15y ago

As much as I respect Nutter's achievements and his jvm chops, his response reads like nitpicking based on his misreading/misunderstanding of what Dart guys wrote and what they meant by it. The position of Dart guys is simple: by compiling an arbitrary language (Dart in this case) to x86 (or whatever native arch the browser is running on) they can get a much faster code than compiling to an abstract VM, like JVM or .NET or parrot. It's not a controversial statement: JVM ultimately compiles to x86 too, so whatever optimization tricks JVM does to generate fast code can be used by a compiler that goes directly from source to x86. The opposite, however, is not true: JVM does introduce an additional layer and fixes in stone many things other than just the instruction set that make compilation of some scenarios from jvm to efficient x86 impossible. And you can't fix that without introducing incompatibilities i.e. breaking existing code. One example of this is class format layout: it has known problems, many of which were fixed in Dalvik. Dalvik, not being jvm, can fix them, but jvm can't without fragmenting the platform. Nutter doesn't exactly contradict the fact that targeting x86 directly results in faster code but all his nitpicking is designed to give that impression. For example, because Dart paper mentioned in passing that JRuby can't be made as fast as native Ruby, he tears into that because JRuby is actually close to Ruby 1.8 in performance. Which, of course, proves nothing. The best JavaScript implementation on JVM is on par, performance-wise, with the old, pre-V8 JavaScript interpreters. V8, Nitro, and Mozilla's various Monkeys all beat that 10-20x, easy. Nutter latches to the unfortunate example Dart paper gave but completely ignores other examples that do show that targeting x86 is, indeed, 10-20x win for dynamic languages. When the paper says that jvm lacks features to implement at least some possible language features efficiently (like built-in instructions for tail-calls) and you can't do anything about. Nutter interprets it as some literal "JVM does not let you do what Java cannot do" but instead of addressing the point (lack of certain primitives needed for fast implementation of certain construct) he again use the JRuby-Ruby 1.8 speed parity as somehow showing Dart guys are wrong. In "A bytecode VM is more than just bytecode" he uses turing-machine argument: both jvm and x86 is turing complete therefore they're just as good. He tops with really weird statement like "Compiling to x86 works best if your feature set fits x86" (if your feature set doesn't fit x86, there it doesn't fit anything). He also brings invokedynamic as a pro-JVM argument disregarding the fact that it's a recent addition to JVM that breaks backwards compatibility - you can't run Java program that uses invokedynamic on older JVMs because they don't understand it. I could go on. This post is just nuts. Here's the real kicker: Nutter is the same guy who develops Duby and Mirah, a static Ruby-look-a-likes. Why does he develop Mirah? From http://www.mirah.org/ http://www.mirah.org/: "No performance penalty Because Mirah directly targets the JVM’s type system and JVM bytecode, it performs exactly as well as Java."

deleted 15y ago
[deleted]
extension 15y ago
The position of Dart guys is simple: by compiling an arbitrary language (Dart in this case) to x86 (or whatever native arch the browser is running on) they can get a much faster code than compiling to an abstract VM, like JVM or .NET or parrot. No, their position is against creating a new VM for the Dart language, and they justify it, in part, by saying it would end up with the same limitations as the JVM. Nutter isn't arguing with this position though, he is just countering their assertions about the JVM.
- kkowalczyk 15y ago
  Except all his argument are by proxy. Is it not true that "the JVM assumes you want classes, single dispatch, inheritance, and primitives. It assumes you don't need 32-bit unsigned math." ? Is it not true that "adding new bytecodes increases the complexity of VM? That to add "all possible languages a VM needs to support a multitude of calling conventions: tail calls, optional arguments, rest arguments, keyed arguments, overloaded methods, and so on" ? Is it not true that "jvm specifies a class file format, a concurrency model (in the case of the JVM threads with shared state), class initialization, and a bunch of other stuff that nails down semantic choices." ? Those are the actual "assertions" made by Dart paper. Which of those facts about jvm Nutter actually countered?
- rayiner 15y ago
  > by saying it would end up with the same limitations as the JVM No, they were saying that it would end up with a different set of limitations, and gives the JVM as an example. E.g. if you exposed the current Dart VM's feature set as a byte code VM, ML folks would complain it doesn't support tail calls, Haskell folks would complain it doesn't allow them to efficiently encode their TABLES_NEXT_TO_CODE optimization, etc. Java folks would complain it's integer semantics are wrong (overflow to bignum rather than wrap-around), that it lacks support for arbitrary class loading, etc.
  - 15y ago

jws 15y ago

mappu 15y ago
I'm not signed in, and the server didn't seem to set any cookies.. Here's a plaintext copy: http://cr6nh1.pen.io http://cr6nh1.pen.io (though the formatting might be better suited to pastebin)
roopeshv 15y ago
i am not signed it, and I still read the article. I keep hearing this complain all the time with google groups. Is it specific to only few or are they based on assumption that it's a google group?
- chc 15y ago
  It's a weird bug with Google Groups. As far as I can tell, if you aren't signed into any Google service at the time, it will let you in. But if you are signed into another Google service, Groups will demand you re-authenticate.
rmc 15y ago
To counter what others are saying, I was being asked to sign in to view this article. (Though as @chc points out < http://news.ycombinator.com/item?id=3384888 http://news.ycombinator.com/item?id=3384888 > I am signed into another Google property on my work email account, so perhaps that's why it's asking me )
azylman 15y ago
Groups doesn't track which articles you read, even if you're signed in.

azylman 15y ago

Let's link to the prettier version of Groups instead of the old, out-dated one... https://groups.google.com/a/dartlang.org/forum/#!topic/misc/u_jk0906sYg https://groups.google.com/a/dartlang.org/forum/#!topic/misc/...

cemerick 15y ago
"Let's link to the glam version of Groups instead of the old, usable one..." Fixed that for you.
- _Y_ 15y ago
  "Let's link to a internally consistent version of Groups that doesn't look like the old familiar one..." Fixed it for you.

azakai 15y ago

The response is right to correct various errors in the original article. But it also misses the point. Yes, JRuby is fast in comparison to other Ruby implementations. But this says nothing, because in general "normal" C and C++ code can be converted to run on the JVM with similar speed to the original: The JVM (the standard one) is very good at that sort of thing. But, there are kinds of code that do not run fast on the JVM. Examples of that are self-modifying code. Ruby implementations happen to not rely heavily on that, so running them on the JVM is fast. However, other dynamic languages that are much faster than Ruby do rely on those techniques, critically so. There has been a lot of effort to bring those advanced techniques to managed runtimes like the JVM, with the goal of running dynamic languages on them quickly. But overall, native implementations are still far faster. For that reason, Microsoft didn't implement a new JS engine on .NET, it wrote a native one, and for the same reason Google is developing a new Dart VM instead of reusing an existing VM (although, that isn't completely true because Dart also compiles to JavaScript, so it can reuse existing VMs, presumably efficiently because the language design clearly shows signs of being optimized to run fast when compiled to JS).