Linked by Thom Holwerda on Thu 13th Sep 2012 20:00 UTC, submitted by MOS6510
Mozilla & Gecko clones "Over the past year and a half I've been spending more and more of my time working with Mozilla's latest project, Firefox OS. During that time I've fallen in love with the project and what it stands for, in ways that I've never experienced with a technology platform before." I'm not convinced just yet. I hope it succeeds, but I just doubt it actually will.
Thread beginning with comment 534982
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Another fallen mobile OS.
by Lennie on Thu 13th Sep 2012 23:53 UTC in reply to "RE: Another fallen mobile OS."
Lennie
Member since:
2007-09-22

The slowest part isn't JavaScript, hasn't been for a while.

Communication with the HTML-document has always been the slowest part. This is because you are crossing boundries and the page might need to re-render.

Most of the things people should avoid doing are known.

If your Firefox installation supports WebGL proper (see: about:support ) you can run WebGL games fairly close to what the hardware can give you. Just see the demo at: https://developer.mozilla.org/demos/detail/bananabread

For example I use https://addons.mozilla.org/en-US/firefox/addon/pdfjs/ which is a lot faster than loading some plugin or reader. The rendering itself isn't much slower actually.

The slowers part of the language itself is that it is dynamically typed. But that has been solved by detecting the type and by introducing types for large sets of data (Typed Arrays).

Java can be very close to C/C++ performance for a number of things, but definitely not everything. And the startup performance of Java usually sucks.

Javascript is now with proper type support for most things about twice as slow as Java or C.

If you remember that languages like PHP or Perl are 100 times slower than C, then you should see it's not that bad. For example Lua without JIT is something like 50 times slower than C.

Reply Parent Score: 6

Alfman Member since:
2011-01-28

Lennie,

I have to admit that's a cool demo. It only partially worked in FF before an update. Hopefully mozilla doesn't make a habit of imposing version incompatibilities (to be fair, at least this was documented).

I think they may have gotten the high res and low res reversed because High res worked ok (though it did pause briefly at intervals for me) and "Low res" was unusable.

The graphics look great, obviously opengl should render the same under the control of any language. Also with the resources being preloaded even a modest performing language should be able to run fluidly - at least until the number of in-game objects imposes a game engine bottleneck.

All in all it's certainly impressive. Never the less, as a developer I would prefer to build on top a well tuned native game engine rather than one implemented in javascript. For my own curiosity, I compared GCC and Firefox on these two. I'll share those results here:

int main(int argc, char *argv[]) {
int x=0;
for(int a=0; a<50000; a++) {
for(int b=0; b<a; b++) {
x=(x+(a^b))&0xffff;
}
}
printf("%d",x);
return 0;
}


<script>
var t0=new Date().getTime();
var x=0;
for(var a=0; a<50000; a++) {
for(var b=0; b<a; b++) {
x=(x+(a^b))&0xffff;
}
}
var t1=new Date().getTime();

document.getElementById('out').innerHTML=x + ' ' + (t1-t0) + ' ';
</script>


GCC=1.26s
JS=4.1s
(I had to actually change my initial test because javascript was timing out.)

I'd say that's not bad at all, all things considered. Here's a more difficult test to measure object overhead.




int main(int argc, char *argv[]) {
float x=0;
unsigned int count=10000;
COORD*coords[count];
for(unsigned int i=0; i<count; i++) {
coords[i] = malloc(sizeof(COORD));
coords[i]->x=i;
coords[i]->y=i;
coords[i]->z=i;
}
for(unsigned int j=0; j<count; j++) {
for(unsigned int i=0; i<count; i++) {
coords[i]->x=(coords[i]->x+coords[j]->y)/2;
coords[i]->y=(coords[i]->y+coords[j]->z)/2;
coords[i]->z=(coords[i]->z+coords[j]->x)/2;
}
}
for(unsigned int i=0; i<count; i++) {
x+=coords[i]->x+coords[i]->y+coords[i]->z;
free(coords[i]);
}
printf("%f",x);

return 0;
}



<script>
var t0=new Date().getTime();
var count=10000;
var x=0;
var coords=new Array(count);
for(var i=0; i<count; i++) {
coords[i] = new Object();
coords[i].x=i;
coords[i].y=i;
coords[i].z=i;
}
for(var j=0; j<count; j++) {
for(var i=0; i<count; i++) {
coords[i].x=(coords[i].x+coords[j].y)/2;
coords[i].y=(coords[i].y+coords[j].z)/2;
coords[i].z=(coords[i].z+coords[j].x)/2;
}
}
for(var i=0; i<count; i++) {
x+=coords[i].x+coords[i].y+coords[i].z;
coords[i]=null;
}

var t1=new Date().getTime();


document.getElementById('out').innerHTML=x + ' ' + (t1-t0) + ' ';
</script>


GCC=0.34s
JS=3.07s

That's pretty bad. Anything that makes heavy use of objects is going to suffer.

I ran some more tests to eliminate allocation & initialisation overhead with similar results. On the one hand, this could be great for a "scripting language", but on the other it would be very disappointing if this scripting language was aiming to replace native ones in practice since 90% of the CPU utilisation might be lost to language overhead.

Reply Parent Score: 3

galvanash Member since:
2006-01-25

This would roughly cut your runtime roughly in half:

var t0=new Date().getTime();
var count=10000;
var x=0;
var coords=new Array(count);
var coord_i = null;
var coord_j = null;

for(var i=0; i < count; i++) {
coords[ i ] = [ i,i,i ];
}

for(var j=0; j < count; j++) {
coord_j = coords[j];
for(var i=0; i < count; i++) {
coord_i = coords[ i ];
coord_i[0]=(coord_i[0]+coord_j[1]) * .5;
coord_i[1]=(coord_i[1]+coord_j[2]) * .5;
coord_i[2]=(coord_i[2]+coord_j[0]) * .5;
}
}

for(var i=0; i < count; i++) {
x+=coords[ i ][0]+coords[ i ][1]+coords[ i ][2];
}

var t1=new Date().getTime();
document.getElementById("out").innerHTML=x + ' ' + (t1-t0) + ' ';


Not that is matters much... I'm not suggesting this is as an optimization, I just wanted to point out that only about half of the performance difference is due to object access overhead in your example - the rest is just pure overhead due to it being interpreted. Converting from objects to arrays (with a few minor optimizations here and there) only cuts the runtime in half.

When I profile this in Chrome 90% of the execution time ends up being engine overhead (parsing, compilation, etc). The actual time spent running the meat of the code itself is only about 10-15ms.

Just saying while scripting overhead is not exactly a fixed cost - it tends to be inversely proportional to the amount of code you write. In other words the bigger and more complex the application is, the less it matters...

In a contrived example like this - all you are really demonstrating is that a scripting language has high overhead costs relative to a compiled language when your code is essentially doing nothing useful in a tight loop.

I wouldn't make the arguement that Javascript is an ideal language for doing computationally intensive stuff - but then again that isn't what it is for. Still, it isn't half bad compared with other interpreted languages...

Edited 2012-09-14 10:02 UTC

Reply Parent Score: 3

Lennie Member since:
2007-09-22

What usually happends with game engines is they port an existing engine (like the demo) to Javascript with the use of https://github.com/kripken/emscripten

I think this is the talk/demo which explains it best:

http://blip.tv/jsconfeu/alon-zakai-emscripten-5666035

Reply Parent Score: 2

bouhko Member since:
2010-06-24

I agree that most of the problem is the document/JS boundary.

Still, I've played a bit with WebGL and it can be quite fast when using static scene data and therefore the JS code only upload the data to the graphic card and that's it. If you start doing things in JS between each frame (like trying to add a physic engine or animate lot of stuff), then performances quickly drop.

That being said, I would be happy to be proven wrong. It's just that claiming that JS games on mobile* run just fine without any proof triggered some alarms.

* I've written a small Android game and I had to write most of it in C++ to get decent performances on low-end devices.

Reply Parent Score: 2

Lennie Member since:
2007-09-22

Game-engines are ported from C/C++ to Javascript with emscripten:

https://github.com/kripken/emscripten

I believe this is the talk/demo you might want to watch:

http://blip.tv/jsconfeu/alon-zakai-emscripten-5666035

Reply Parent Score: 3