Comment by patio11 | Hacker News Reader

Comment by patio11 | Hacker News Reader

Parent Full thread

the overhead of the interpreted language is going to slow things down as compared to something compiled down to the metal

Welcome to the Java vs. C debate, previously the C vs. assembler debate, previously the assembler versus hand-coding machine code debate. Computers these days, even netbooks, are fast. Very, very breathtakingly fast.

There has also been a significant amount of work done in VMs, much related to Java, which has delivered tremendous performance boosts to interpreted languages. Google has a very talented VM team working on Chrome's JS execution engine (SpiderMonkey or something, can't remember off the top of my head).

But really, after you get past Wolfenstein done in Javascript (http://www.nihilogic.dk/labs/wolf/ ) how more does the typical user actually need? After that it isn't a matter of CPU cycles, its the programmers coming up with non-painful ways to develop software to use them.

BS. There are never enough cycles.

First, SpiderMonkey is the next-gen JS engine for FireFox. V8 is the Google JS engine.

Second, Flash Player 10 is as good or better than any JS engine (with the possible exception of V8), and many Flash games bog on my netbook.

Just one example, but, as more capable web apps come online, the bar will rise, and more cycles will be called for.

You're right that this is similar to the Java vs. C (or C++) debate. And, as with that debate, the answer is that, for many application domains, native code has a significant performance advantage.

On windows and mac, your point about Flash 10 being faster than JS is probably true. However, Flash 10 on Linux is BUGGERALL SLOW. Fullscreen Youtube videos are jerky and slow on my 2.2ghz processor. JS is much faster on Linux than Flash.

When you're on mobile devices, the game changes a bit. It's not just about running fast enough, it's also about not draining too much battery. Sure, netbooks last 4-8hrs nowadays... but I'm pretty sure that wouldn't be the case with 90% CPU utilization all the time.

I'm all for high-level languages. But it's going to take some optimization to get there.

I'm not sure that it is the same debate.

Javascript doesn't compile down to any sort of bytecode. It is just a chunk of raw source. Anything of the techniques that you'd apply (like JIT), would occur after a compile on the client.

That seems like a pretty fundamental difference to me.

And playing a 17 (!!) year old game doesn't strike me as a particularly convincing argument. You're effectively saying that javascript is some 2^(17/1.5) ~= 2000x slower than compiled C.

Reply on news.ycombinator.com