Why, after decades of JIT bytecode VMs, do we still have this misconception? Many of the widespread JVM implementations are faster than V8. LuaJIT and C# Mono are also VM implementations that JIT bytecode and are faster than V8! Is this a troll?
As people have commented, I'm suggesting writing a javascript function which takes pre-compiled bytecode; like so;
function interpret(bytecode) {
// stack machine implementation goes here
}
And called like so;
var bytecode = load("http://my.domain.com/myscript.bytecode");
interpret(bytecode);
I'm not suggesting that bytecode is inherently slow -- just that I could take a great stab at writing a slow bytecode interpreter in JavaScript. ;)
So under this scheme, you could do a server-side compilation of any language -- let's imagine Pascal as an example -- and deliver it back to the client as bytecode. Now you've broken the browser dependence on Javascript. At the cost of a VM written in JavaScript.
I'm suggesting writing a javascript function which takes pre-compiled bytecode
Sorry, I misunderstood.
Now you've broken the browser dependence on Javascript. At the cost of a VM written in JavaScript.
I keep looking at these two sentences again. On one hand I know what you mean. On the other hand, this doesn't make any sense because it contradicts itself. (Which is why I misunderstood the original comment, I think.)
The post you replied to seemed to be suggesting a VM written in Javascript. I don't think it's particularly controversial to speculate that the performance of that would be pretty awful :)
Why, after decades of JIT bytecode VMs, do we still have this misconception? Many of the widespread JVM implementations are faster than V8. LuaJIT and C# Mono are also VM implementations that JIT bytecode and are faster than V8! Is this a troll?
http://shootout.alioth.debian.org/u32/which-programming-lang...