"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.
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.
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.
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.
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.
"""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."""
Reasoning: you're doing it wrong.
1) That JRuby is faster than Ruby 1.8/1.9 is not saying much.
Maybe x86 Ruby's implementation was not good enough from the start, and JRuby made a clean start. Perhaps you can make a x86 Ruby many times faster than JRuby with the right time.
What it does prove, by doing it, is that you can practically implement a language on JVM to be faster than a x86 language, despite the latter having much earlier head start and dev count.
2) That V8 is dramatically faster than any other implementation of a dynamic language on JVM DOES NOT PROVE the point of Dart paper that "x86 gives much more opportunity for optimization than jvm".
It could be just that implementations of dynamic languages on the JVM are toy projects with small teams working on them, while Google spend tons of dollars on a top-notch PhD team to work on V8. I certainly do now know of a JVM dynamic language with much money and team resources. Even stuff sponsored by Spring Source have much much less resources than Google's V8 team.
Also, check the benchmarks page you point to. Java is right up there in speed after C/C++/Fortran, and much much before x86 targeting v8. That's proof that nothing precludes a VM language being DAMN FAST.
And that's on the JVM, a VM almost set in stone, except of a few recent additions, and with a huge burden of backwards compatibility. Even better things could be achieved with a modern, unburdened, VM.
And the Dart team could even design it around the needs of the Dart language, most people would be happy with that, if it used a bytecode other languages could target.
Oh, and nothing precludes adding an AOT compilation system to a VM/JIT language.
Room for optimization suggests when time is taken you get a faster code. After all this time and all these optimizations the JVM is still terrible for 3D code and zero blockbuster games uses it. Sure, it's possible for JVM code to be on par with poorly optimized code, but that does not mean there is equal headroom for optimization. Worse yet, for web code you can't use the old standby of having the JVM call C or ASM code for truly critical code.
EX: You could probably get a minecraft clone to run faster on the JVM but that's because the game engine is crap not because JVM has any advantage.
"""Room for optimization suggests when time is taken you get a faster code. After all this time and all these optimizations the JVM is still terrible for 3D code and zero blockbuster games uses it."""
I don't think Sun was particularly good at optimizing in this particular task --or even interested.
They worked towards their actual customer use, ie. the server side.
It's not just 3D code, even desktop UI libs (Swing, JavaFX) and multimedia code where left without much (or any) love from Sun (/Oracle).
That doesn't mean a VM is unsuitable for fast 3D. Don't tons of 3D games use the Unity engine, which utilizes the Mono VM?
And it's not like critical 3D parts of the implementation cannot be written in plain old C/C++/ASM -- and exposed to the web programmers via some VM interface (a special set of 3D specialized opcodes? an intermediary 3D extension language + lib other vm languages will have to use? I dunno, it's however totally possible)
So if Mono (a VM language) can do fine in 3D games usage, it proves that nice 3D performance is not incompatible with a VM language --which is what the parent suggested, bringing up Java 3D performance as an example.
And again I am talking about headroom, it does not take state of the art graphics to make a great game, but it does take a non VM language for the graphics subsystem.
PS: Computers are FAST my cellphone would crush multimillion dollar super computers when I was in high school. So, generally trading speed for nicety's like virtual memory is well worth it. However, that does not mean we are avoiding the tradeoffs just accepting them with open arms.
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.
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.
"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.
"""Sure but that not the point. Dart would (just like JS) run on some kind of VM with a JIT."""
Actually that's the whole point, and that's what the Dart guys said they don't want to do and it's not fast enough.
"""If the[y] would open the code for that VM it would have problems just like the JVM has."""
Like what? Name one (1) problem the JVM has had because of making bytecode available as a target.
That other languages trying to run on the JVM had some performance problems and needed some opcodes and stuff is no a problem the JVM shared --it was an optimization request. And the theoretical Dart VM would not even have to have those problems, because unlike Java/JVM, it can be designed from the start to be dynamic.
And it's not like there weren't totally competent language implementation targeting the JVM before invokedynamic and other "nice-to-haves".
"Actually that's the whole point, and that's what the Dart guys said they don't want to do and it's not fast enough."
Im 99% sure that the Dart team is building a VM with a JIT for Dart. There goal is to be faster then JS this will not be possible without some kind of JIT. Like I said, the question is if the have some kind of bytecode (any IR) that can be targeted. How else can the make a it fast? They send the sourcecode from the server to the client there is no time for a fully optimizing compiler.
"Like what? Name one (1) problem the JVM has had because of making bytecode available as a target."
Well the JVM dosn't have any problems the language running on it have problems.
"And the theoretical Dart VM would not even have to have those problems, because unlike Java/JVM, it can be designed from the start to be dynamic."
Dynamic typing is not the only problem of the JVM. Implmenting everything that every programming language needs is not possible. Sure you can design any VM and with time make it better for more and more languages.
This however comes with a price, for example VM complexity. Cliff Click who worked on the original Sun JVM and did a complete rewrite of it for Azul talks about this, why do you think it to that many years until the JVM bytecode changed? Complexity. If you really want to evolve the language your bytecode will have to change witch means the VM must change two. If Dart ran on an open Dart VM it would be much harder to change the VM and the overall implmentation.
My Final points:
(1) Designing a fast VM (bytecode, JIT, GC ....) is hard.
(2) If you want to make a VM that is good for many languages it even harder.
(3) Goole wants Dart not a generic VM (or at least the rather have a fast Dart short term then a generic VM with a Dart impmentation that takes much longer to develop and much more work to maintain.)
(4) I agree that we want generic Web VM.
(5) Somebody (w3c for example) should start a process to work on something like this. Gathering proposals, encourage smart people to thinkg about this.
> They send the sourcecode from the server to the client there is no time for a fully optimizing compiler.
The solution that the Dart VM and other JS VMs to is to compile twice: you do a very fast simple compile so that you can start executing code quickly and reduce start-up time. Then you find frequently-used functions and recompile them using a more advanced optimizing compiler. This is why many modern VMs have a "warm-up" period: code will get faster over time as it gets recompiled more optimally.
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.