6 ms·

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

by jshen 15y 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.

kkowalczyk 15y 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&lang=jruby&lang2=v8 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.
- jshen 15y ago
  "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 15y ago
    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 15y ago
      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.
- dextorious 15y ago
  """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.
  - Retric 15y ago
    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.
nickik 15y 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.
- dextorious 15y ago
  """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".
  - nickik 15y ago
    "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.
jeltz 15y 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-july-2010/ 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.
oelewapperke 15y ago
Exactly. The GP is entirely wrong. Reality works in the very opposite way. Theoretically, bytecode VMs can beat native machine code because they can do all sorts of stuff that you can't do in native code (or at least, nobody's ever come close to doing them yet). An example of what can be done in the JVM (this is actually done) : add %l1, 5000 jo recompile_this_function_with_longs_and_reexecute I dare anyone to implement this in native code, never mind in 5 kinds of native code (like google would have to do, ie. x86, x86-64, and the 3 arm variants that android runs on). It is possible to do that. But the complexity of doing that is ridiculously high, so nobody's going to do that any time soon. Here's the only reality : the google programmers of Dart have their own small isolated community and simply have little experience doing that, and do not feel like getting their hands dirty (or there's too few of them ...). It is work, with a nice payoff, but still a lot of work. And of course, they don't want to admit this. What I don't understand is what is wrong with using an existing bytecode vm inside chrome ? Why not run hotspot inside chrome and have all those languages simply work ?

by jshen 15y ago

kkowalczyk 15y 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&lang=jruby&lang2=v8 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.

jshen 15y ago
"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 15y ago
  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 15y ago
    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.
dextorious 15y ago
"""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.
- Retric 15y ago
  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.

nickik 15y 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.

dextorious 15y ago
"""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".
- nickik 15y ago
  "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.

jeltz 15y 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-july-2010/ 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.

oelewapperke 15y ago

Exactly. The GP is entirely wrong. Reality works in the very opposite way. Theoretically, bytecode VMs can beat native machine code because they can do all sorts of stuff that you can't do in native code (or at least, nobody's ever come close to doing them yet). An example of what can be done in the JVM (this is actually done) : add %l1, 5000 jo recompile_this_function_with_longs_and_reexecute I dare anyone to implement this in native code, never mind in 5 kinds of native code (like google would have to do, ie. x86, x86-64, and the 3 arm variants that android runs on). It is possible to do that. But the complexity of doing that is ridiculously high, so nobody's going to do that any time soon. Here's the only reality : the google programmers of Dart have their own small isolated community and simply have little experience doing that, and do not feel like getting their hands dirty (or there's too few of them ...). It is work, with a nice payoff, but still a lot of work. And of course, they don't want to admit this. What I don't understand is what is wrong with using an existing bytecode vm inside chrome ? Why not run hotspot inside chrome and have all those languages simply work ?