Mozilla building mobile OS to battle Chrome(download.cnet.com)
download.cnet.com
Mozilla building mobile OS to battle Chrome
http://download.cnet.com/8301-2007_4-20083238-12/mozilla-building-mobile-os-to-battle-chrome/
8 comments
I wish people would stop calling the act of scraping together a new linux distro "writing an OS."
This may seem obvious but operating systems tend not to be replaced by other operating systems, but rather subsumed by the very applications built on top of them.
For example, DOS was not replaced by another OS but was subsumed by a DOS application, Windows 3.1, which eventually grew down and became a standalone OS in Windows 95.
For example, DOS was not replaced by another OS but was subsumed by a DOS application, Windows 3.1, which eventually grew down and became a standalone OS in Windows 95.
DOS << Windows << Browser << Facebook
Great thread! So the next thing to expect after the Chrome laptop would be a Facebook laptop?
My biggest problem with this is that the biggest problem with Mobile web browsers right now is that they pale in comparison (both feature and performance) to their desktop counterparts. Last time I checked the iPad browser (probably the best tablet browser) was something like 15x slower than Chrome desktop in javascript benchmarks.
This is the #1 blocker to mobile web app adoption. Try viewing a SVG on a mobile browser and see what happens. You're flipping a coin. Why doesn't Mozilla focus on bringing mobile/desktop feature parity before adding device level APIs?
This is the #1 blocker to mobile web app adoption. Try viewing a SVG on a mobile browser and see what happens. You're flipping a coin. Why doesn't Mozilla focus on bringing mobile/desktop feature parity before adding device level APIs?
With regards to performance, keep in mind that there is simply a difference in processor performance. A mobile architecture browser is just not going to be as fast as a desktop based browser.
There are additional optimizations that can be done, of course--the ARM assembly generated by current JITs is not of quite the same quality as the x86 assembly, because the architectures are structured differently and ARM was shoe-horned in afterwards. Different ways of performing operations do better on ARM than on x86--the architectures have different performance characteristics. In point of fact, some of the JS team at Mozilla has shifted focus to improving ARM code generation.
Second, you are assuming that everyone at Mozilla works on the same single project. This is simply not so. There will still be a significant team of people working on improving the current mobile Firefox. This new project is distinct.
There are additional optimizations that can be done, of course--the ARM assembly generated by current JITs is not of quite the same quality as the x86 assembly, because the architectures are structured differently and ARM was shoe-horned in afterwards. Different ways of performing operations do better on ARM than on x86--the architectures have different performance characteristics. In point of fact, some of the JS team at Mozilla has shifted focus to improving ARM code generation.
Second, you are assuming that everyone at Mozilla works on the same single project. This is simply not so. There will still be a significant team of people working on improving the current mobile Firefox. This new project is distinct.
Please educate me, I honestly don't know, but I've tested html5 games on an iPad2 and a 5 year old single core PC and seem the PC consistently outperform the iPad2. What is it about ARMs that are so slow compared to the equivalent or worse x86 chip?
I'm completely supportive of this project, and would probably use it on my personal phone, I just wonder if Mozilla isn't already stretched too thin.
I'm completely supportive of this project, and would probably use it on my personal phone, I just wonder if Mozilla isn't already stretched too thin.
There's a few aspects to discuss here.
Firstly, in 2006 (5 years ago), x64 chips were Core2Duos clocked at about 2.2Ghz. This is top of the line, but even a mid-level processor would be something like 1.6Ghz. A PC would probably have about 2GB of RAM.
An iPad2 is a 1GHz, dual core device. Further, it is built for a mobile device, and thus will sacrifice performance for the sake of battery life, at the very least in subtle ways. It has 512MB of RAM. That's not quite equivalent, not yet. Certainly the next round of mobile hardware will be above and beyond the level of said desktops by a good margin.
Second, there is the performance profile characteristics I mentioned before. I don't know much of the details of ARM, but for example: you can only load a 12-bit immediate. Larger constants must be loaded into a constant pool. The iPad's L1 cache is significantly smaller than that of a desktop processor. Both have 16 general purpose registers, but spilling to the stack will take more of a hit on ARM.
Then there is code quality. Current codegen for ARM is not as good as x64--checking the tag and performing a conditional jump in Jaegermonkey currently produces 3 instructions where it could be done in 1 instruction. When an constant is loaded into the constant pool there is no check to see whether it was necessary to load it (was it already loaded in?) There was a lot of focus on code generation quality in x86-land which has only recently been shifting to ARM--I expect those pieces of the puzzle to be solved very quickly.
To address your other point, what information is indicative of Mozilla being "stretched too thin"?
(For my credentials when talking about Firefox's Javacsript JIT--I am an intern currently working on the next generation JS JIT, Ionmonkey. Code is here: http://hg.mozilla.org/projects/ionmonkey/)
Firstly, in 2006 (5 years ago), x64 chips were Core2Duos clocked at about 2.2Ghz. This is top of the line, but even a mid-level processor would be something like 1.6Ghz. A PC would probably have about 2GB of RAM.
An iPad2 is a 1GHz, dual core device. Further, it is built for a mobile device, and thus will sacrifice performance for the sake of battery life, at the very least in subtle ways. It has 512MB of RAM. That's not quite equivalent, not yet. Certainly the next round of mobile hardware will be above and beyond the level of said desktops by a good margin.
Second, there is the performance profile characteristics I mentioned before. I don't know much of the details of ARM, but for example: you can only load a 12-bit immediate. Larger constants must be loaded into a constant pool. The iPad's L1 cache is significantly smaller than that of a desktop processor. Both have 16 general purpose registers, but spilling to the stack will take more of a hit on ARM.
Then there is code quality. Current codegen for ARM is not as good as x64--checking the tag and performing a conditional jump in Jaegermonkey currently produces 3 instructions where it could be done in 1 instruction. When an constant is loaded into the constant pool there is no check to see whether it was necessary to load it (was it already loaded in?) There was a lot of focus on code generation quality in x86-land which has only recently been shifting to ARM--I expect those pieces of the puzzle to be solved very quickly.
To address your other point, what information is indicative of Mozilla being "stretched too thin"?
(For my credentials when talking about Firefox's Javacsript JIT--I am an intern currently working on the next generation JS JIT, Ionmonkey. Code is here: http://hg.mozilla.org/projects/ionmonkey/)
As of Firefox 5, I think, Mobile Firefox is released from the same revision of the same source tree as Desktop Firefox, and should have all the same web-facing features available. Of course, they might not run at the same speed - that's just hardware - but I would expect SVG for example to display identically on the desktop and on a mobile device.
"Mozilla will seek to propose new standards to address the challenges that emerge during development"
I'd love to be able to get excited about this, but sadly I can't. Here's why: http://xkcd.com/927/
Plus, like someone already said, Mozilla is maybe stretching itself a bit too thin.
I'd love to be able to get excited about this, but sadly I can't. Here's why: http://xkcd.com/927/
Plus, like someone already said, Mozilla is maybe stretching itself a bit too thin.
I dream of a future of sophisticated mobile web apps and no vendor lock-in to a particular mobile OS.
Ok somewhat confused the article implies its to battle Android not Chrome..?
Mozilla's biggest problem is not aligning with wants of mobile OEMs..
Right now a significant part of mobile OEMs wants mobile widget engine technology..such as BONDi..Mozilla could be ahead of the game by putting BONDi inside their engine for mobile..
My bias; exactly 18 months ago was interviewed by Mozilla for an xml dev job and suggested that very path.
Right now a significant part of mobile OEMs wants mobile widget engine technology..such as BONDi..Mozilla could be ahead of the game by putting BONDi inside their engine for mobile..
My bias; exactly 18 months ago was interviewed by Mozilla for an xml dev job and suggested that very path.
A foundational goal of the B2G project is to explore and remedy areas where current Web standards are insufficient for building modern mobile applications. Instead of haphazardly grafting vendor-specific markup or extensions into the application runtime, Mozilla will seek to propose new standards to address the challenges that emerge during development.
Nicely aligns with their main aim of promoting openness, innovation and opportunity on the web.[2]
[1] http://arstechnica.com/open-source/news/2011/07/mozilla-eyes...
[2] http://www.mozilla.org/about/mission.html