3 ms·

>Besides: I can't think of language-neutral bytecode projects that ever worked. Remember Parrot? Really? Remember the CLR and JVM?

by batista 14y ago

MatthewPhillips 14y ago
Where are the CLR or JVM implementations of JavaScript that run as fast as V8 or Chakra?
- jfoutz 14y ago
  I can't speak to the CLR, but the JVM isn't bad at all. http://shootout.alioth.debian.org/u32/javascript.php http://shootout.alioth.debian.org/u32/javascript.php But, microbenchmarks, blah blah blah.
- batista 14y ago
  What that has to do with anything? The post I replied to said that "language neutral bytecode project neve worked" and brought up Parrot as an example. He was not specific to them not working for Javascript. Now, besides off context, your comment is wrong in four ways: 1) we are not discussing about a bytecode to implement Javascript, but a bytecode to use in browsers for implementing all sorts of languages. 2) There are other lnguages that have been implemented in CLR/JVM that are faster than Javascript. 3) V8 has been optimized by a special team, for millions of dollars, with speed as the #1 target. When that amount of money and effort, a JS running on JVM/CLR can be fast too. 4) A bytecode does not preclude a JIT. In fact it would be trivial to have V8 run a bytecode instead of raw js, just as Python runs pyc.
  - MatthewPhillips 14y ago
    JavaScript is very relevant because there is tons of legacy code that has to run equally as fast in this new bytecode VM as it runs today under the various engines. The choice of VM comes down to how well it works with dynamic languages. JVM and CLR are both modeled after statically typed languages. Microsoft spent quite a bit of money trying to put JavaScript on top of .NET but finally gave up, and today it places it's IE platform on equal footing with .NET.
lerouxb 14y ago
You're right. I should have explicitly specified "aimed at dynamic languages". Compiling dynamic languages to CLR or JVM sortof works, but is less than ideal. And "ideal" (or more suitable, at least) language-neutral bytecode projects have never taken off.

>Besides: I can't think of language-neutral bytecode projects that ever worked. Remember Parrot? Really? Remember the CLR and JVM?

by batista 14y ago

>Besides: I can't think of language-neutral bytecode projects that ever worked. Remember Parrot? Really? Remember the CLR and JVM?

MatthewPhillips 14y ago

Where are the CLR or JVM implementations of JavaScript that run as fast as V8 or Chakra?

jfoutz 14y ago
I can't speak to the CLR, but the JVM isn't bad at all. http://shootout.alioth.debian.org/u32/javascript.php http://shootout.alioth.debian.org/u32/javascript.php But, microbenchmarks, blah blah blah.
batista 14y ago
What that has to do with anything? The post I replied to said that "language neutral bytecode project neve worked" and brought up Parrot as an example. He was not specific to them not working for Javascript. Now, besides off context, your comment is wrong in four ways: 1) we are not discussing about a bytecode to implement Javascript, but a bytecode to use in browsers for implementing all sorts of languages. 2) There are other lnguages that have been implemented in CLR/JVM that are faster than Javascript. 3) V8 has been optimized by a special team, for millions of dollars, with speed as the #1 target. When that amount of money and effort, a JS running on JVM/CLR can be fast too. 4) A bytecode does not preclude a JIT. In fact it would be trivial to have V8 run a bytecode instead of raw js, just as Python runs pyc.
- MatthewPhillips 14y ago
  JavaScript is very relevant because there is tons of legacy code that has to run equally as fast in this new bytecode VM as it runs today under the various engines. The choice of VM comes down to how well it works with dynamic languages. JVM and CLR are both modeled after statically typed languages. Microsoft spent quite a bit of money trying to put JavaScript on top of .NET but finally gave up, and today it places it's IE platform on equal footing with .NET.

lerouxb 14y ago

You're right. I should have explicitly specified "aimed at dynamic languages". Compiling dynamic languages to CLR or JVM sortof works, but is less than ideal. And "ideal" (or more suitable, at least) language-neutral bytecode projects have never taken off.