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

https://groups.google.com/a/dartlang.org/group/misc/browse_thread/thread/bbf8e4d3dd3ab188

by johnbender • 15 years ago

135 43 15 years ago

groups.google.com

jws• 15 years ago

mappu• 15 years 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 (though the formatting might be better suited to pastebin)

roopeshv• 15 years 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• 15 years 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• 15 years 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 > I am signed into another Google property on my work email account, so perhaps that's why it's asking me )

azylman2• 15 years ago

Groups doesn't track which articles you read, even if you're signed in.

kkowalczyk3• 15 years 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/:

"No performance penalty

Because Mirah directly targets the JVM’s type system and JVM bytecode, it performs exactly as well as Java."

extension2• 15 years ago

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.

kkowalczyk3• 15 years 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• 15 years 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.

nickik7• 15 years ago

"No, their position is against creating a new VM for the Dart language"

This is just WRONG. The will implment some kind of VM for Dart anyway (maybe the put it into V8 but I doute it). The question is if the should open up the bytecode (some IR) so other people can compile to that. There argument is that this VM for Dart would have limitations just like the JVM has them. Therefore opening the VM for other people is not worth it.

jshen2• 15 years ago

"so whatever optimization tricks JVM does to generate fast code can be used by a compiler that goes directly from source to x86"

Aren't there some optimizations you can do at run time that you can't do at compile time?

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

JRuby is much much faster than 1.8.

There are a number of other places you are getting details or choice of words wrong.

kkowalczyk3• 15 years ago

Fine, JRuby is much faster than 1.8.

V8 is orders of magnitude faster than JRuby on most benchmarks: http://shootout.alioth.debian.org/u32/benchmark.php?test=all...

Jruby is faster only on one.

That's why I call this nitpicking.

JRuby being faster than Ruby 1.8 proves nothing other than Ruby is not especially optimized.

V8 being dramatically faster than any other implementation of a dynamic language on JVM proves the point of Dart paper: x86 gives much more opportunity for optimization than jvm.

This is even more relevant if you consider the number of people who worked on jvm and the age of jvm compared to the same numbers for v8.

nickik7• 15 years ago

"Aren't there some optimizations you can do at run time that you can't do at compile time?"

Sure but that not the point. Dart would (just like JS) run on some kind of VM with a JIT. If the would open the code for that VM it would have problems just like the JVM has. If the should open it or not is a sepret discussion.

jeltz• 15 years ago

"JRuby is much much faster than 1.8."

Why are we even comparing JRuby and Ruby 1.8? Ruby 1.9.3 is the last version and Ruby 1.9 is much faster than Ruby 1.8.

In a benchmark from last year JRuby and 1.9 were about equally fast with 1.9 the winner in most cases. With the recent improvements in JRuby I believe JRuby is faster but I have no idea about how much.

http://programmingzen.com/2010/07/19/the-great-ruby-shootout...

EDIT: Note that Ruby 1.9 gained in performance compared to 1.8 due to the introduction of a new Ruby targeted VM, YARV. Previously I believe it ran directly on the AST.

nickik7• 15 years ago

I agree with you. Nobody can argue that compiling to the Java Bytecode (and running on Hotspot) is just as good as compiling to x86. Just because JRuby beats native rubys dosn't mean anything. I would be willing to bet that somebody like Mike Pall or other JIT experts could implment a JIT for Ruby that beats the hell out of JRuby. (Not to say JRuby is bad or something, an effort like this would take more time then implmenting JRuby, I'm just saying it could be done).

Sure everything is turing complet but that says nothing about performace. The JVM does not have tail call optimization but you can simulate it on the heap if you want. Same for all the other assumtions that are in the JVM.

From a buisness-perspectve Dart does the right thing and there arguments are valid. The could just open the Dart VM bytecode so other people could plug-in there but that would make it harder for them to change the VM.

I would much rather see a standard bytecode for some generic Web VM. How a bytecode would look is kind of a research problem. There are many other problems to solve befor something like Web VM model would work. The w3c should maybe start a process that goes in that direction (start gathering proposals, make people think about the problem).

dextorious6• 15 years 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."""

And, I believe, the position of the web community at large is: we much rather have a VM than a faster lame language with small chances of success over js.

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

A problem which a new "web vm" will NOT have. Being new, and able to go any way it likes...

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

Actually JRuby was already faster than Ruby 1.8/1.9, and with the latest changed to the VM (invokedynamic etc), is around 3 (THREE) times faster that plain Ruby. Check the recent HN story on that.

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

I seriously doubt the "10-20x win". References?

munificent2• 15 years ago

I'm one of the two people who wrote the article in question. Thanks for this response. This is much closer to what we were trying to express than the impression that many people (including Nutter) seem to have gotten out of it. It's reassuring that at least some readers were able to make sense of the general points we wanted to convey.

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

Not just that, but that's is much simpler and easier to do so. It may be possible to get just as fast with a public intermediate bytecode format, but the amount of work required would be much much greater. Given how much effort it already takes to create a new language and all of the surrounding infrastructure (we're designing the language, iterating on it, writing a spec, building a VM, writing compilers, filling out the core library, writing tools, editors, documenting, evangelizing, etc.), anything we can do to minimize effort is a good idea.

strmpnk• 15 years ago

JRuby outperforms most other Ruby implementations today by a large ratio from all my testing of non-trivial code. That isn't the point though. This is still a comparison with either immature JIT implementations or pure interpreters so I don't think it really means much.

I will say that he is right to be annoyed that anyone would claim JRuby is slower since it isn't in all cases I've tested.

opinali• 15 years ago

This kind of article is always a minefield and a huge bait for debates, even more when it's part of the advocacy for some new programming language (who doesn't love language fights?). It's important to be very precise, adhere to standard and well-known terminology, be very clear about the scope of each claim, have necessary disclaimers about benchmarks etc. or you are just asking for trouble. :) Your (kkowalczyk's) reply has some good points ("...if your feature set fits x86" indeed Charles was tired or something to write that), but it does have several flaws too. You get the concept of "backwards compatibily" completely wrong: adding a new feature like invokedynamic that prevents NEW code to run on OLD runtimes does not break BW compat. Java's track record in BW compat is almost perfect (modulo bugs). JRuby's results in the language shootout are produced with HotSpot Client, that's why they are so bad, JRuby depends massively on HotSpot Server. For benchmarks that critically depend on certain features like fixnums, a VM like YARV will certainly beat JRuby easily; but this doesn't mean "general-purpose VM cannot compete with specialized VM", it only means "VM without special support for feature X may not compete with VM that has X, in a benchmark that stresses X".

The real discussion in the performance aspect of "bytecode VM" vs. "language VM" is much more subtle. A "language VM" will not convert source code directly to native code either; it will use one or more Intermediary Representations, from ASTs to classic SSA LIR/HIR. So it's easy to argue that these are equivalent to bytecodes; and one can just design some bytecode format that is basically an externalized form of your IR, then there's no disadvantage of performance or limitation for two-stage compilation with a JIT. But now the discussion moves to evolution and flexibility. IR forms can be completely changed in new releases of the compiler/VM, because they are internal. But as soon as you're tied to an external representation, you're stuck to evolving that much more conservatively, or with much extra effort, not only for the VM but for the entire third-party toolchain ecosystem that targets the bytecode. This is the major problem that the Dart article should have raised. There's still the possibility of creating some truly universal bytecode - LLVM's bitcode may fill these shoes for unmanaged languages; and something similar could be designed for managed languages although that's harder because a managed heap and memory model necessarily means some set of restrictions that will get in the way of some languages, at least the very lowest-level ones. Dart is Google's attempt to provide a better managed language for the web (without bytecode), while NaCl is their attempt to provide a better support for unmanaged languages (with either native code / NaCl or LLVM bitcode / PNaCl], so they're trying to cover all corners and it will be very interesting to see how each of these developments work out.

azylman2• 15 years 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/...

cemerick• 15 years ago

"Let's link to the glam version of Groups instead of the old, usable one..."

Fixed that for you.

_Y_• 15 years 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• 15 years 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).

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

Related Stories