> Basic issue is the same and it's very-well known: use of technologies which hog resources like crazy (interpreted language plus garbage collection), only in Android it can be mitigated because you can easily move heavy-duty computations to native code which is impossible for FirefoxOS.
Nonsense, Firefox has asm.js which allows for near-native speed.
Posted Sep 5, 2013 10:39 UTC (Thu) by khim (subscriber, #9252)
[Link]
Nonsense, Firefox has asm.js which allows for near-native speed.
... if you have uncounted gigabytes of RAM. Native code is not just about speed, it's about memory consumption, too. On mobile both are at premium. ASM.js promises 0.5x speed for a single core CPU and to achieve that it still needs gobs of RAM.
Yes, asm.js can narrow gap between FirefoxOS and Android, but it's still will be quite large.
Firefox OS on the ZTE Open
Posted Sep 5, 2013 21:35 UTC (Thu) by ibukanov (subscriber, #3942)
[Link]
> if you have uncounted gigabytes of RAM
asm.js does not add any penalty to the size of native data structures. They take exactly the same amount of memory as if directly compiled to the machine code. Clearly, the runtime support for parsing and compiling the initial code can be high, but even in that case we are talking about tens of megabytes, not hundreds, that are immediately returned to the system after the native code is generated.
Firefox OS on the ZTE Open
Posted Sep 6, 2013 11:36 UTC (Fri) by khim (subscriber, #9252)
[Link]
asm.js does not add any penalty to the size of native data structures.
May be not for data structures, but it defenitely has huge penalty for code. Contemporary applications are huge and with asm.js you can not even share basic LibC routines! I've seen projects where people created their own linker to reduce memory pressure by reusing PLT tables. This is on top of the already shareable code (it's not loaded in memory but used via mmap(2) on all contemporary OSes).
Clearly, the runtime support for parsing and compiling the initial code can be high, but even in that case we are talking about tens of megabytes, not hundreds, that are immediately returned to the system after the native code is generated.
Even if they are returned it's enough to push other important structures out of memory and, more importantly, you still need to keep all these duplicated libraries in memory even after initial load. Sure, this problem is solveable with caching and other clever techniques, but AFAICS it's not done yet. Eventually all these problems will be "solved" in a simple way (via use of the excessively fast hardware), but… time is running out.
P.S. Note that my asm.js skepticism is opposite of GC skepticism: with GC I'm not sure if it's ever possible to create workable solution (in a case where memory and CPU power is a premium) while with asm.js I'm ready to admit that everything is possible in theory, but we are not there right now.
Firefox OS on the ZTE Open
Posted Sep 5, 2013 16:50 UTC (Thu) by b7j0c (subscriber, #27559)
[Link]
asm.js does nothing for string/DOM manipulation which is most of what you will see in web apps. asm.js applies to a very limited subset of js.