Firefox OS on the ZTE Open [LWN.net]

Firefox OS on the ZTE Open

Posted Sep 5, 2013 10:39 UTC (Thu) by khim (subscriber, #9252)
In reply to: Firefox OS on the ZTE Open by HelloWorld
Parent article: Firefox OS on the ZTE Open

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.

(Log in to post comments)

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.