Firefox OS on the ZTE Open [LWN.net]

Firefox OS on the ZTE Open

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

It seems, unlike with android, to be a purely optimization issue.

Really? IMNSHO it's the other way around: there are some hope for Android yet nothing can make FirefoxOS responsive on the hardware where Android is laggy.

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.

For instance, when running it as a firefox plugin on the desktop, performance is perfect (lag is virtually undetectable, even more responsive than gnome shell!).

Of course. You are throwing 10 times (or may be 20, 50, 100 times) more resources on the task then said task actually needs - no wonder it can be solved in such a way. But it's hard to produce "cheap phone for emerging markets" which have 10x more power then is needed for sane solutions (like iOS, for example).

That's why FirefoxOS can never win direct fight with Android or iOS: it's basic architecture makes sure it'll not be competitive. It can probably produce poor experience for poor people who don't know any better and with advances in hardware it may even become usable, but in direct confrontation FirefoxOS will lose 10 times out of 10 - it's architecture guarantees that. When mobile phones will be as powerful as today's desktop computers it'll be smooth enough, but by that time we'll already know the winner of "smartphone war" and it'll be as entrenched as Windows is today.

(Log in to post comments)

Firefox OS on the ZTE Open

Posted Sep 5, 2013 9:50 UTC (Thu) by HelloWorld (subscriber, #56129) [Link]

> 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.

Firefox OS on the ZTE Open

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.

Firefox OS on the ZTE Open

Posted Sep 5, 2013 9:54 UTC (Thu) by ibukanov (subscriber, #3942) [Link]

> in Android it can be mitigated because you can easily move heavy-duty computations to native code which is impossible for FirefoxOS.

Mozilla's answer to that is asm.js, http://asmjs.org . Although currently it may not provide native speed in all cases, the nice thing about is that it is very light in terms of efforts to develop it so Mozilla can improve it very quickly.

Firefox OS on the ZTE Open

Posted Sep 5, 2013 17:06 UTC (Thu) by b7j0c (subscriber, #27559) [Link]

the only way for mozilla to address string/DOM manipulation would be through language extensions (in which case they lose the "its just js" selling point), or craft their rendering engine to special case what is recognized as asm.js output (possible, but would bloat the rendering engine and create weird bugs)

the v8 folks keep telling people that further optimization of js runtimes is limited due to the nature of the js language...but mozilla can't look at alternatives without giving the appearance of losing their independence

Firefox OS on the ZTE Open

Posted Sep 5, 2013 21:15 UTC (Thu) by roc (subscriber, #30627) [Link]

As someone who has done a lot of work on performance issues in FirefoxOS, and someone dogfooding FirefoxOS on the lowest-end hardware, I don't agree. I don't know exactly what issues Corbet is complaining about, but most of the slowness/lag issues I see are not GC related.

One big issue is app startup time. This is related to Web platform issues --- it's hard to precompile a Web app --- but not GC.

Another big issue is smoothness of CSS animations and transitions. These are managed by C++ code and GC is not involved.

Another big issue is smoothness of panning with touch gestures. Again these are managed by C++ code that isn't impacted by GC.

(Our JS GC has gotten a lot better since the version of Gecko that's present in these 1.0 devices. We have greatly reduced pause times since then. I don't think that will make much difference to FirefoxOS users though.)

Firefox OS on the ZTE Open

Posted Sep 6, 2013 11:29 UTC (Fri) by khim (subscriber, #9252) [Link]

This is related to Web platform issues --- it's hard to precompile a Web app --- but not GC.

I've said "interpreted language plus garbage collection", not just GC. If you say that first part is more problematic then second one then you probably are right. Both are pretty awful but their combination is especially bad.

Another big issue is smoothness of panning with touch gestures. Again these are managed by C++ code that isn't impacted by GC.

I'm not all that sure. I've never worked with FirefoxOS but I've played with Android. Once when we've tried to see why panning does not work smoothly after small change we've found that one, single Java-based printf in the frame-generated procedure generated over 200 temporary objects and created lags. We've replaced Java printf with C++ code and problem went away. Granted it was an old version of Android and the old hardware (original Android device: HTC Dream), and I hope there are nothing so bad in FirefoxOS but I would not dismiss the possibility entirely: even if 99% of work is done in C++ you still can not be sure GC will not hurt you. Note that while said HTC Dream is considered fatally underpowered by modern Android standards it's not all that worse then ZTE Open from purely hardware standpoint.

Our JS GC has gotten a lot better since the version of Gecko that's present in these 1.0 devices. We have greatly reduced pause times since then.

Bwahaha. I first heard this excuse over twenty years ago when I was still in middle school and asked why some "uberpowerfull" text editor (don't remember the name, but I know it was not Emacs) periodically stops responding and displays "GC in progress, please wait" message. Few years later I've tried to use Whitewater Resource Toolkit in Borland C++ 3.0, met the same problem and heard the same excuse. I've heard it bazillion times since then and this is why I don't believe in GC.

P.S. Note that I could be wrong. I was similarly sceptical about C++ decision to create the standard library with huge amount of garbage which is supposed to be optimized away by optimizing compiler — yet C++ guys have provent me wrong since today compilers indeed know how to optimize all that mess and the result is often faster then nice and clean C code. I will be ready to admit that GC is no longer a problem when I'll see UI with GC and no lag — but not before. Actually I have seen such UI. In Emacs. But if please recall that Emacs means "Eight Megabytes And Constantly Swapping" and notice that today even mobile phones have hundred times more then that… it's not very convincing.

Firefox OS on the ZTE Open

Posted Sep 6, 2013 12:48 UTC (Fri) by danieldk (subscriber, #27876) [Link]

> (Our JS GC has gotten a lot better since the version of Gecko that's present in these 1.0 devices. We have greatly reduced pause times since then. I don't think that will make much difference to FirefoxOS users though.)

Will these devices get such updates? How long will a phone such as the ZTE Open get Firefox OS updates?

BTW. It's great to see more competition!

Firefox OS on the ZTE Open

Posted Sep 6, 2013 18:08 UTC (Fri) by Lennie (subscriber, #49641) [Link]

I've read somewhere that Mozilla's play is to have regular updates like Firefox and Chrome on the desktop for the top part of FirefoxOS (so not the kernel and daemons).

Firefox OS on the ZTE Open

Posted Sep 5, 2013 22:43 UTC (Thu) by liam (subscriber, #84133) [Link]

Really? IMNSHO it's the other way around: there are some hope for Android yet nothing can make FirefoxOS responsive on the hardware where Android is laggy

I'm not saying there's no hope for Android. The problems with android seem down to: unoptimized drawing routines, scheduling issues, and uneven drivers. Since fxos is using android as a delivery for kernel/drivers, it's going to suffer from the driver issues as well. The scheduling may be something they could fix though it's not in their area of expertise. The drawing pipeline, however, could be a rather large difference. I've related my experience with running it with faster hardware and how the lag virtually vanishes. I haven't told of my experiences with android with various hardware.

Regarding native code, I think you are vastly underestimating how much of the pertinent code paths are actually using native code (apparently c++ according to roc below). This becomes increasingly the case as they use fully accelerated css paths rather than custom js.

Of course. You are throwing 10 times (or may be 20, 50, 100 times) more resources on the task then said task actually needs - no wonder it can be solved in such a way. But it's hard to produce "cheap phone for emerging markets" which have 10x more power then is needed for sane solutions (like iOS, for example).

I think you're missing the point. Running android 4.1 on my old nexus s results in similar levels of lag as the highest-end android devices. To stay with nexus devices and using geekbench for rough estimates of device capabilities, the nexus 4 is roughly seven times more powerful, yet, the lag difference is imperceptible to me. Thus my point about optimizations in the two platforms.

I get that you have disdain for interpreted languages, and I'm not going to argue the point, but I think you are wrong about this b/c I've never used an android device that didn't have that characteristic lag, and I have used a firefox "device" that didn't.

Lastly, running geekbench on my computer (core2duo t7500 with 4GB) it actually scored lower than my nexus 4 (which is a bit odd since the pc actually posted individual scores of about twice the nexus 4 for single core results), so we're not talking about huge performance deltas here.

Firefox OS on the ZTE Open

Posted Sep 6, 2013 11:20 UTC (Fri) by khim (subscriber, #9252) [Link]

Running android 4.1 on my old nexus s results in similar levels of lag as the highest-end android devices.

Have you actually compared them side-by-side or are you comparing experiences separated by years?

I've recently was forced to work with Nexus S (with Android 4.1, naturally) for a bit and quickly found out that it's laggy as hell when compared to Galaxy Nexus with Android 4.2.x/4.3 (I don't have Nexus 4). When I've used it as my primary phone years ago I've not noticed these same lags all that much.

To stay with nexus devices and using geekbench for rough estimates of device capabilities, the nexus 4 is roughly seven times more powerful, yet, the lag difference is imperceptible to me.

I'm not sure what exactly geekbench measures, but biggest problem with interpreted languages is not even CPU power, but memory consumption. You need gobs of memory to make them fast (on a desktop a single Chrome tab with GMail uses over 200Mb while the phone we are talking about only has 256MiB available).

Lastly, running geekbench on my computer (core2duo t7500 with 4GB) it actually scored lower than my nexus 4 (which is a bit odd since the pc actually posted individual scores of about twice the nexus 4 for single core results), so we're not talking about huge performance deltas here.

No, we are talking about some limited benchmark here. Raw computing power of "big" Intel CPUs may not be all that dissimilar from raw CPU power of ARM in synthetic benchmarks, but there are huge diffence in real life because of faster memory, bigger caches, better prefetch logic, etc. Also: are you sure you are comparing apples-to-apples and your "core2duo t7500 with 4GB" actually has proper 3D acceleration and everything? Latest versions of Android rely on GPU for various effects and software fallback is not optimized all that well. If CPU power is wasted on doing GPU effects (which even top Intel CPUs are not doing all that well), then of course interface will be laggy.

Firefox OS on the ZTE Open

Posted Sep 6, 2013 16:51 UTC (Fri) by ibukanov (subscriber, #3942) [Link]

According to about:memory gmail tab under Firefox on ARM takes 64 MB. Not good, but manageable on 256MB phone.

Firefox OS on the ZTE Open

Posted Sep 6, 2013 22:00 UTC (Fri) by liam (subscriber, #84133) [Link]

Have you actually compared them side-by-side or are you comparing experiences separated by years?

Side-by-side. The Nexus S still works as it always has (well, not considering the changes the updates have made).

I've recently was forced to work with Nexus S (with Android 4.1, naturally) for a bit and quickly found out that it's laggy as hell when compared to Galaxy Nexus with Android 4.2.x/4.3 (I don't have Nexus 4). When I've used it as my primary phone years ago I've not noticed these same lags all that much.

The lag have ALWAYS been there in every device, regardless of spec. The frame rates have been a bit worse since 4.1 came out. The input latency seems about the same (I can't say for certain since I wasn't able to test those side-by-side, of course).

***SNIP interpreted language rant***

I'm not going to do your research for you, so if you want to know what geekbench measures you can look for yourself, but I will say this: it categorizes its tests as int, fp, and memory/streaming performance. The memory category was of particular interest to me since that has been a consistent weak area for ARM. The intel cpu had a better memory interface (upto about four times better).