

Charlie Nutter's Response to "Why Not A Bytecode Vm" - johnbender
https://groups.google.com/a/dartlang.org/group/misc/browse_thread/thread/bbf8e4d3dd3ab188

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

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

~~~
kkowalczyk
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...](http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=jruby&lang2=v8)

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.

~~~
jshen
"That's why I call this nitpicking"

I don't think pointing out numerous inaccuracies from technical experts is nit
picking. Your larger point may be true, I have no idea, but Charles was
pointing out real misstatements about the JVM.

~~~
fauigerzigerk
As I'm reading it, Nutter is blatantly misstating what the Dart guys say in
order to create most of those "inaccuracies". For instance, he summarizes the
Dart article as saying "2. JVM does not let you do what Java cannot do" and
"3. A bytecode VM can't support all possible language features".

Where do the Dart guys say that? The entire Dart article is clearly about
biases and limitations to _optimizations_ and not about what a language can or
cannot do in the sense of Turing completeness. Nutter is creating a bunch of
straw men here.

He also decides to ignore all but one of the examples the Dart guys give. They
talk about unsigned math, tail call elimination, restartable conditions,
continuations, and static/dynamic typing (I would add structured value types).
He only responds to dynamic typing because that's where he might actually have
a point.

~~~
jsnell
Restartable conditions don't require any VM support that isn't also needed for
normal exceptions. Even in CL implementations they're simply built on top of
the normal non-local control flow construct (throw/catch) and dynamically
scoped variables. And the latter are easy to implement in terms of try-finally
even if not supported natively.

The tricky bit with restartable conditions is that you need to support them
everywhere, or they're pretty useless. So they aren't going to be very
interesting in a multi-language environment like the JVM even if they're easy
to implement.

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

------
jws
Sign in and be tracked to read an article? Thank you, no.

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

------
azylman
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/...](https://groups.google.com/a/dartlang.org/forum/#!topic/misc/u_jk0906sYg)

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

Fixed that for you.

~~~
_Y_
"Let's link to a internally consistent version of Groups that doesn't look
like the old familiar one..."

Fixed it for you.

