5 ms·

* web based applications don’t require that much horsepower on the client end so it should be faster still* I've heard this a lot and I simply don't buy it. A

by sanj 17y ago

* web based applications don’t require that much horsepower on the client end so it should be faster still* I've heard this a lot and I simply don't buy it. Assuming that the apps are Javascript-based (which all of Google Apps are today), the overhead of the interpreted language is going to slow things down as compared to something compiled down to the metal. It is possible that Google will go the route of using its NativeClient, but that'd be a pretty big departure.

patio11 17y ago
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/ 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.
- Sindisil 17y ago
  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.
  - ramidarigaz 17y ago
    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.
- sanj 17y ago
  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.
- costan 17y ago
  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.

by sanj 17y ago

patio11 17y ago

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/ 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.

Sindisil 17y ago
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.
- ramidarigaz 17y ago
  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.
sanj 17y ago
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.
costan 17y ago
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.