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 535010
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Another fallen mobile OS.
by Alfman on Fri 14th Sep 2012 05:42 UTC in reply to "RE[2]: Another fallen mobile OS."
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

Alfman Member since:
2011-01-28

galvanash,

"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 to be clear, this example did NOT measure script parsing overhead, which was mere milliseconds on my machine and an acceptable one-time cost. What was slow was the run time inside the loop - several seconds in each case. I'm baffled why you're claiming 90% of the execution time is due to "parsing, compilation, etc"? Obviously we can't be talking about the same thing.


"Converting from objects to arrays (with a few minor optimizations here and there) only cuts the runtime in half. "

There are several ways we could have eliminated the objects, but given that they were what I was measuring the overhead of this would have defeated the point.


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

Maybe I could of/should have implemented a vector multiplication benchmark to be less contrived, but I doubt it would have improved the performance of javascript objects, which is still a problem.


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


Fair enough, but if HTML apps continue to displace native ones for things like game engines, that's kind of where we'll end up.


"Still, it isn't half bad compared with other interpreted languages... "

Agree, I think it's a pretty good language & the implementations of it aren't bad either.

Reply Parent Score: 2

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