4 ms·

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

"""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.
- dextorious 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.""" 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)
  - rodrigokumpera 15y ago
    Maybe it just means that Mono is much more well suited for games and embedded usage. Which arguably is the case.
    - dextorious 15y ago
      Only we're not discussing Mono vs JVM here. We're discussing VM vs non-VM languages. 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.
      - Retric 15y ago
        Mono VM just demonstrates my point. You can use it to make games with that would have had reasonable graphics 7 years ago but no so much today. EX: http://www.unearthedgame.com/ http://www.unearthedgame.com/ which is around Half Life 2 graphics which came out in 2004. http://store.steampowered.com/video/220/904 http://store.steampowered.com/video/220/904 Feel free to look for a better example from: http://unity3d.com/gallery/made-with-unity/game-list http://unity3d.com/gallery/made-with-unity/game-list 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.

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.

dextorious 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.""" 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)
- rodrigokumpera 15y ago
  Maybe it just means that Mono is much more well suited for games and embedded usage. Which arguably is the case.
  - dextorious 15y ago
    Only we're not discussing Mono vs JVM here. We're discussing VM vs non-VM languages. 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.
    - Retric 15y ago
      Mono VM just demonstrates my point. You can use it to make games with that would have had reasonable graphics 7 years ago but no so much today. EX: http://www.unearthedgame.com/ http://www.unearthedgame.com/ which is around Half Life 2 graphics which came out in 2004. http://store.steampowered.com/video/220/904 http://store.steampowered.com/video/220/904 Feel free to look for a better example from: http://unity3d.com/gallery/made-with-unity/game-list http://unity3d.com/gallery/made-with-unity/game-list 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.