| 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[7]: Another fallen mobile OS. |
| By Alfman on 2012-09-15 17:18:16 |
|
galvanash, "I was simply pointing out that it isn't purely because of object access. Object access is slower of course, but the bulk of the time is actually spent on engine level stuff (like memory allocation)." If I understood you correctly, you may be suggesting that JS only spent ~20ms (we're handwaiving here) doing actual work and the rest was language support overhead. That's a peculiar thing to say, but I guess that's plausible. However I don't see why it changes anything because the overhead is still there regardless of what you attribute it to. Hopefully there is room for improvement. "That is my point though - only about 40% of that overhead you measured is due to object access. I removed it and the code runs 2x as fast, but it is still more than 50x slower than GCC. The big difference is memory allocation and general engine overhead." Well, just for kicks I've rerun my original code but with a new timer around the inner loop. entire script=3.032 inner loop = 3.027 So I think we can rule out memory allocation overhead as a culprit (Unless javascript is continuously reallocating memory unnecessarily in the inner loop?). Still impressive compared to JS engines from a few years go, but I think further optimisation is going to be increasingly difficult. "Like I said, that isn't a fixed cost - it is highly dependent on the code. But it does tend to become less and less significant the larger and more complex the code base becomes." You know I can't let you get away with a statement like that without some kind of evidence :) Edited 2012-09-15 17:21 UTC |
 - Score: 2 |
| RE[2]: Comment by Luke McCarthy |
| By Alfman on 2012-09-15 17:48:22 |
|
adkilla, "I wouldn't want the stagnation that is happening in the x86 platform to extend to ARM SoCs. If it weren't for AMD, we would all be stuck with a 32-bit ISA on x86, with an overly costly and less than optimal upgrade path to Itanium. Unfortunately we've lost the 3rd party chipset market on x86 due to having too few CPU players." Haha, I was actually very disappointed with AMD when they told the world they were going to extend the life of x86 with a 64bit variant of it. I sincerely thought that we would be migrated to better architectures by now if AMD hadn't anchored us right back to the x86 platform (albeit with some improvements). The AMD64 ISA still suffers from a lack of GP registers compared to alternatives, which necessitates complex hacks like register renaming. The opcodes are still highly inconsistent, increasing the amount of logic needed to parse them. The whole architecture is shrouded in subtle legacy designs. I guess we have to wait for a newcomer to replace x86-64, but now that x86 is 64bit that could take a while (x86-64 could conceivably last a few decades like the x86 did). |
| - Score: 2 |
| RE[3]: Comment by Luke McCarthy |
| By adkilla on 2012-09-15 18:56:17 |
| Given the choice over Itanium and x86-64, I'd take x86-64 anyday. |
| - Score: 2 |
| RE[8]: Another fallen mobile OS. |
| By galvanash on 2012-09-16 02:42:04 |
|
Well... I withdraw most of what I posted... It turns out Chrome's profiler does some very weird shit when you are profiling naked code in the global scope. I rewrote the code so that it is contained in a function, so that all the variables are local. The timing didn't really change, but what changed was where Chrome was reporting % of time spent... Long story short - Array access is faster than Object access, but either way that is where the majority of time is being spent in your test code. Hell - I don't know exactly what Chrome was reporting before when it was showing 10-15ms... It ends up reporting things completely differently once you get out of the global scope. I just assumed it was reporting things correctly... sorry about that. If you instead did something focusing on the calculations involved and less on the object access (obviously this wont give the same result)... > function dostuff() { var i=9999; var coords=new Array(i+1); var ci,cj; console.profile(); while(--i) { coords[ i ] = (i + i) / 2; coords[ i ] = (coords[ i ] + i) / 2; coords[ i ] = (coords[ i ] + i) / 2; } console.profileEnd(); } You end up with this taking only about 6ms on my machine... Same operations same number of times - just no object access and a simpler loop with just one control variable. So all in all I would say your original observation was dead on - most of the delta between GCC and JS in your example is purely object access. |
| - Score: 2 |
| RE[3]: Comment by Luke McCarthy |
| By zima on 2012-09-16 13:47:19 |
|
> I was actually very disappointed with AMD when they told the world they were going to extend the life of x86 with a 64bit variant of it. I sincerely thought that we would be migrated to better architectures by now if AMD hadn't anchored us right back to the x86 platform [...] The whole architecture is shrouded in subtle legacy designs. I don't think so - if you'd take AMD out of the equation, the world would just mostly continue buying x86-32 until really hitting that 4 GiB limit ...at which point MS would just save the day by forcing PAE in their then-new (and in that alternative reality) Vista/7, and that would be it (assuming Intel management wouldn't come to their senses prior to that) Generally, over time everything collects & grows in legacies... And considering the most likely "better" alternatives, can you really say with a straight face that we would be better off without x86-64? (consumers in general - sorry, nobody cares about asm, OS, compiler devs :P ) Still, in a few years you might more or less get what you want(?) - the Loongson ~MIPS chips have hardware-assisted x86 emulation. Considering all the x86 licensing issues, it's of course unlikely to show up in "current" (in the future) ~Western products ...my guess: it's there (and being worked on) to be ready when P5, MMX, P6, SSE patents lapse in the coming decade (I think) - that subset of x86 should allow running virtually all really important(tm) legacy software, a perspective probably very appealing to the Chinese, in their supposed quest to technology independence. So, you just have to move to PRC to experience it, or at least to the areas likely within their sphere of influence in the future ;p (that should be SE Asia and large parts of Latin America and Africa ...though who knows, maybe more ;p ) |
| - Score: 2 |
| RE[2]: Comment by Luke McCarthy |
| By zima on 2012-09-16 14:11:39 |
|
> I wouldn't want the stagnation that is happening in the x86 platform to extend to ARM SoCs. If it weren't for AMD, we would all be stuck with a 32-bit ISA on x86, with an overly costly and less than optimal upgrade path to Itanium. Unfortunately we've lost the 3rd party chipset market on x86 due to having too few CPU players. I guess MS would just save the day by forcing PAE in Vista/7, in that alternative reality (if Intel wouldn't wise up sooner) ...overall, probably not much of a difference to us. And 3rd party chipsets were likely going out anyway, due to increasing integration of x86 platforms (so not exactly stagnation, and even similar in spirit to ARM SoCs). Anyway, if there would be more x86 chipsets thanks to there being more x86 CPU players ...those chipsets wouldn't really be 3rd party, wouldn't they :p (plus, while we might despair the loss of ULi or SiS, I won't miss VIA chipsets; but BTW SiS, x86, and SoCs... http://en.wikipedia.org/wiki/Vor... ) Edited 2012-09-16 14:23 UTC |
| - Score: 2 |
| RE[9]: HTML as a toolkit for a mobile OS? |
| By Nelson on 2012-09-16 17:52:18 |
|
> I'm very principled... One of my first principles is that I don't believe that development is the process of becoming attached at the hip to a particular vendor's idea of the right way to do things. HTML/JS might not be perfect, but it has one very significant feature that no other development platform has - no one company is steering the boat. XAML and C# are open specifications. There is nothing proprietary about them. They're also a great deal better than HTML/JS, so let's drop the straw man. Anyone is free to implement a XAML parser. I'm not tied to any particular platform because my back end code has no ties to any platform. Its all generic .NET code. It works across the myriad platforms I'm interested including a great majority of the smartphone market. > And since you want to resort to name calling... What is being content to slop up Microsoft or Apple's latest dog food for the sake of it making things easier for you? That sounds pretty lazy to me. My development platform is the world - yours is just the latest gadget fad... I don't? The only parts Cocoa or XAML are the native front ends. A great majority of my code is portable across platforms. I custom tailor my apps for the platform, while you try to make HTML fit everywhere , user experience be damned. |
| - Score: 2 |
| RE[9]: HTML as a toolkit for a mobile OS? |
| By Nelson on 2012-09-16 17:54:18 |
|
You do this really naive thing where you assume you're the moral arbiter of programming and I'm supposed to care about your opinion. Also, my apps feel more native, perform better, and I achive comparable productivity with just slapping together an alien feeling HTML5 website and calling it a day by stuffing it into an app. |
| - Score: 2 |
| RE[4]: Comment by Luke McCarthy |
| By Alfman on 2012-09-16 18:52:34 |
| I wasn't suggesting the choice for 64 bit desktop supremacy was only between intel processors, it's completely ironic that AMD64 is mostly responsible for keeping intel in the lead for 64bit processors. |
| - Score: 2 |
| RE[4]: Comment by Luke McCarthy |
| By Alfman on 2012-09-16 18:56:20 |
|
zima, "Generally, over time everything collects & grows in legacies... And considering the most likely "better" alternatives, can you really say with a straight face that we would be better off without x86-64? (consumers in general - sorry, nobody cares about asm, OS, compiler devs ;) )" Actually, yes I do think so. x86-64 is just the latest in a number of extensions to the antiquated architecture. Sure it's "good enough", but I think x86-64 won at the expense of competitors which will continue to me marginalised for at least another decade. "Still, in a few years you might more or less get what you want(?) - the Loongson ~MIPS chips have hardware-assisted x86 emulation. Considering all the x86 licensing issues, it's of course unlikely to show up in "current" (in the future) ~Western products" There's so much legal BS going down right now that I suspect you might be right. These are sad times. Edited 2012-09-16 18:59 UTC |
| - Score: 2 |
| News | Features | Interviews |
| Blog | Contact | Editorials |