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 534962
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Another fallen mobile OS.
by bouhko on Thu 13th Sep 2012 21:02 UTC in reply to "Another fallen mobile OS."
bouhko
Member since:
2010-06-24

I see a contradiction in the fact that they use HTML5 and JS and that they want it to run on cheap hardware as well as Android.

I highly doubt the claim in the article about javascript game running faster than Android native games. I _really_ want to see some proof of that, because that's really not what I have seen. I mean even on the desktop, HTML5/JS is slow when compared to other technologies.

Also, it's really time for the web browser developers to start working on a real VM for the browser instead of hacking on top of JS. .NET seems like a good example of how you can have a common API shared across multiple languages.

Edited 2012-09-13 21:04 UTC

Reply Parent Score: 8

RE[2]: Another fallen mobile OS.
by Lennie on Thu 13th Sep 2012 23:53 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

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

RE[2]: Another fallen mobile OS.
by ricegf on Fri 14th Sep 2012 12:09 in reply to "RE: Another fallen mobile OS."
ricegf Member since:
2007-04-25

I had to go back and re-read that claim - and the claim is that FirefixOS runs webapps faster than the Android *browser*, not than native apps. And that claim is perfectly believable to me.

Reply Parent Score: 3