| News | Features | Interviews |
| Blog | Contact | Editorials |
| 'There is something magical about Firefox OS' |
| By Thom Holwerda, submitted by MOS6510 on 2012-09-13 20:00:06 |
| "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. |
|
| RE[4]: Another fallen mobile OS. |
| By galvanash on 2012-09-14 09:56:58 |
|
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]+coor d_j[1]) * .5; coord_i[1]=(coord_i[1]+coor d_j[2]) * .5; coord_i[2]=(coord_i[2]+coor d_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("ou t").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 |
 - Score: 3 |
| RE[4]: Another fallen mobile OS. |
| By Lennie on 2012-09-14 10:10:35 |
|
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/emscri... I think this is the talk/demo which explains it best: http://blip.tv/jsconfeu/alon-zak... |
| - Score: 2 |
| RE[7]: HTML as a toolkit for a mobile OS? |
| By galvanash on 2012-09-14 10:37:45 |
|
> Like static typing...it does have a use (though whether you benefit from it is a different matter), it explicitly limits the number of states a variable may hold and helps catch errors at compile time. Exactly. I don't like languages that limit the number of states a variable may hold. And the types of errors that are actually caught by type checking at compile time are generally trivial typos and such. That said, if you do proper unit testing (something you should be doing in either type of language) all the pros of static typing disappear - except for it being faster to compile. Hence why I said that is its only real strength. > var a = x.foo() + 'x'; // what is a? a is a variable :) > For this reason, I'd argue javascript is a poor choice for mission critical applications like those at NASA. Most of the space stuff tends to use plain old C, which might be statically typed but it isn't strongly typed - which is arguably just as bad from an "avoiding errors" point of view... Then again, I have read they use quite a bit of Python at JPL - Python isn't all that different from javascript fundamentally - both are dynamically typed. It sure is prettier though... > There are more problems, like the inability to define proper "classes", which make javascript both slower and less error proof. How does using prototypes instead of class make things slower and less error proof? Its just a different way to skin the cat - they both get the job done equally well if you understand the paradigm. > Again, maybe you prefer not to use classes and find the prototype substitute good enough for you. I don't consider prototyping a "substitute" for classes - it is the sane way to do it :) > But whether it's an enhancement or restriction of the language depends on your point of view - it's a matter of opinion. Agreed. > Also, we've build other languages on top of javascript because browsers don't give us much choice, not because it particularly makes sense to do so otherwise. Whether its javascript or some other language - it makes no sense to deliver an opaque intermediary language representation to a browser that is designed to render human readable markup. The human readable part is important for a multitude of reasons, and that includes the logic too... |
| - Score: 2 |
| RE[2]: Another fallen mobile OS. |
| By ricegf on 2012-09-14 12:09:53 |
| 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. |
| - Score: 3 |
| RE[2]: Most forward-looking |
| By ricegf on 2012-09-14 12:17:04 |
|
"Works Best in IE6" websites didn't work well in Firefox 1.0, either. A few years later, Microsoft was desperately trying to kill IE6 if favor of IE8 - that worked well with Firefox-compatible (standard) sites. Not saying that David will beat Goliath again, but he's 1-0. I'm not betting against him. (I'm anxious to try a FirefoxOS device now. I love the scrappy underdog...) |
| - Score: 2 |
| RE: Comment by Luke McCarthy |
| By ricegf on 2012-09-14 12:28:55 |
|
Suboptimal tech usually wins, unfortunately. Firefox was an anomaly, based on historical precedent we should all still be stuck in IE. I still prefer a native Qt environment like MeeGo, but I'll sacrifice that for true freedom in Firefox OS. If lightning strikes twice, I'm a potential customer. |
| - Score: 2 |
| RE[5]: Another fallen mobile OS. |
| By Alfman on 2012-09-14 15:20:24 |
|
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. |
| - Score: 2 |
| RE[3]: Another fallen mobile OS. |
| By shmerl on 2012-09-14 15:26:18 |
|
May be, but it doesn't seem that anyone besides Samsung is going to release any devices. I'm not even sure that Samsung really will. Edited 2012-09-14 15:26 UTC |
| - Score: 2 |
| RE[2]: Great but... |
| By dmrio on 2012-09-14 16:06:32 |
|
> Did you know that browsers will soon support a whole lot more than just SMS. Yes, I know, and that is exactly my point. Mozilla is pioneering here, so even if the OS platform as a whole fails miserably, their work must be credited. |
| - Score: 1 |
| RE[8]: HTML as a toolkit for a mobile OS? |
| By Alfman on 2012-09-14 16:24:43 |
|
galvanash, "Exactly. I don't like languages that limit the number of states a variable may hold." Other than an ADT, can you give me an example where storing multiple types in one variable is good practice? VB supported both typed and untyped code, plus it did not overload '+' as a concatenation operator, both of these traits help resolve ambiguities we have in javascript. "That said, if you do proper unit testing (something you should be doing in either type of language) all the pros of static typing disappear - except for it being faster to compile." This is not it at all. Throw out compilation speed all together and you'll still find that some programmers prefer rigid constraints to inferences. If I know that I want a boolean, there's no reason the language should force me to use a variable than can store a float, an integer, a string, an object, an array, etc. For me, this is a shortcoming of JS REGARDLESS of performance. Even if variants are better in your opinion, they're not better for everyone. "How does using prototypes instead of class make things slower and less error proof? Its just a different way to skin the cat" The problem with JS objects is the same as the problem with it's variables: it doesn't permit the programmer to be explicit about his intentions at compile time. As for performance, javascript's objects are actually hash tables, very powerful but they're not anywhere as efficient (space or computation) as a static language memory structure. While it is true that JS objects are more flexible at run time, that benefit is completely lost on programmers who (in their own opinion) would benefit more from compile time structure/type checking. "Whether its javascript or some other language - it makes no sense to deliver an opaque intermediary language representation to a browser that is designed to render human readable markup." I don't think being HTML or JS are intrinsically human readable unless that code was written by a human. Ever tried to use a JS optimizer to remove variable names/spacing/comments? It's impossible to read again without reverse engineering it. So to the extent that a human wrote the code, then having source code is nice (even if irrelevant to most users). But I doubt many devs will have reason to work with the intermediate representation even if it is in Javascript. So for running many languages in the browser, we'd probably be better off with a well defined bytecode that can easily be decompiled back into source form (tools exist to do this for java). |
| - Score: 2 |
| News | Features | Interviews |
| Blog | Contact | Editorials |