Linked by Thom Holwerda on Wed 9th Feb 2011 23:29 UTC
Thread beginning with comment 461897
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: Comment by Laurence
by Laurence on Fri 11th Feb 2011 12:43
in reply to "RE[3]: Comment by Laurence"
Yes, worth to note however is that Google uses a JIT-compiler for Javascript rather than interpreting. The JIT-Compiler they bought (V8) is very fast and unlike most other JIT-compilers it converts directly to machine code instead of the traditional bytecode, which means they don't need a 'virtual machine' but instead runs native code.
With both the code generator and the GC being state of the art I can see why Google bought V8. As for performance relative to Java or C#, obviously Java and C# being statically typed gives them an advantage but it would still be interesting to see just how much of a difference there really is.
Given that people write quite advanced games in purely interpreted languages like Python and Lua, there's no reason that JIT-compiled Javascript won't be able to perform well for many tasks given that the really heavy lifting will be done by the underlying system using native code and hardware acceleration, with Javascript merely handling the program 'logic'.
With both the code generator and the GC being state of the art I can see why Google bought V8. As for performance relative to Java or C#, obviously Java and C# being statically typed gives them an advantage but it would still be interesting to see just how much of a difference there really is.
Given that people write quite advanced games in purely interpreted languages like Python and Lua, there's no reason that JIT-compiled Javascript won't be able to perform well for many tasks given that the really heavy lifting will be done by the underlying system using native code and hardware acceleration, with Javascript merely handling the program 'logic'.
while I appreciate that machine code > byte code, but wouldn't there still be additional overhead with compile times using in using a JS JIT compiler?
Granted it would be negligible for web apps, but for larger programs like games, I'd have thought the JIT compiler would become rather noticeable
Also, the mainstreem Python implimentation (CPython) also compiles to byte code - much like the .NET family does. So it's not really a "purely interpreted" language anymore.
In fact I can't speak for Lua, but I think most traditionally interpreted langauages are processed as byte code these days (Perl, Ruby, Python and PHP certainly all do)
Edited 2011-02-11 12:44 UTC




Member since:
2006-01-24
Yes, worth to note however is that Google uses a JIT-compiler for Javascript rather than interpreting. The JIT-Compiler they bought (V8) is very fast and unlike most other JIT-compilers it converts directly to machine code instead of the traditional bytecode, which means they don't need a 'virtual machine' but instead runs native code.
With both the code generator and the GC being state of the art I can see why Google bought V8. As for performance relative to Java or C#, obviously Java and C# being statically typed gives them an advantage but it would still be interesting to see just how much of a difference there really is.
Given that people write quite advanced games in purely interpreted languages like Python and Lua, there's no reason that JIT-compiled Javascript won't be able to perform well for many tasks given that the really heavy lifting will be done by the underlying system using native code and hardware acceleration, with Javascript merely handling the program 'logic'.
Indeed, there's nothing inherit in ObjectiveC that would make it's performance lesser than that of C or C++, this would be a question of the code quality generated by the compiler.