64-bit Firefox for Windows should be prioritized, not suspended
arstechnica.com
arstechnica.com
The web browser has become the most important app on the PC, with more and more web pages demanding more and more resources, I really wish Mozilla would refocus on making the best web browser available.
A few weeks ago I tried to delete some of my history from Firefox, I opened the history window, hit Shift and selected about 6 months of history and hit delete, and it took Firefox about an hour to delete the history all the while the UI going from responding to not responding back and forth. Firefox has some serious performance problems.
[1]. https://blog.mozilla.org/blog/2012/11/20/firefox-introduces-...
EDIT: I'm responding to your edit here:
> A few weeks ago I tried to delete some of my history from Firefox, I opened the history window, hit Shift and selected about 6 months of history and hit delete, and it took Firefox about an hour to delete the history all the while the UI going from responding to not responding back and forth.
I would imagine the Firefox developers spend their time optimizing the parts of their browser that users would most likely use. I suspect that they are not terribly worried about an action that users would take (at most) once every six months.
EDIT2: I guess I'll respond to this one too:
> The web browser has become the most important app on the PC, with more and more web pages demanding more and more resources, I really wish Mozilla would refocus on making the best web browser available.
Making the best web browser is not Mozilla's goal. Their goal is to "promote openness, innovation & opportunity on the Web" [1]. Integrating social features into the browser is part of that, in the sense that users will be able to control their social presence from their browser, rather than being locked-in to a specific social provider's web site. Mozilla's actions are not inconsistent with their stated mission. (Whether you agree with that mission is another argument entirely).
edit: In response to your edit:
>Making the best web browser is not Mozilla's goal. Their goal is to "promote openness, innovation & opportunity on the Web"
If Mozilla's goal isn't to make the best web browser then no one will end up using their browser, and if no one uses their browser then they wont be able to "promote openness, innovation & opportunity on the Web", no market share = no voice. During the days of IE6's dominance Mozilla got its large user base because it was the best browser available. Mozilla is in danger of hemorrhaging users if it continues making these sort of decisions.
Us "hackers" got Mozilla its user base, we started using it first and convinced our family, friends, workmates/workplaces to switch. If the power users leave, the rest will be soon to follow.
I'm surprised only 84% of the traffic is Windows users.
You are also implying that developers using windows are all second rate.
If you subtract that quotient from the general pool of "Windows developers" it becomes much more of a fair comparison.
Yes, there's useful things on w3schools, but like picking through a trash heap full of rusted bicycles and used syringes, it's a dangerous expedition. You might pick up some awful bad habits along the way.
When even the basics are wrong you're not getting refreshed much. Especially when adding three letters ('mdn') to the query at the end gives you a much better resource by all metrics.
Actually, the implication is that second rate developers are Windows users. Which is a very different statement.
That's not referring to Windows users in particular.
[1]: https://en.wikipedia.org/wiki/Usage_share_of_operating_syste...
I stopped using Firefox years ago. Reading an apology on a tech site explaining why, in 2012, it's acceptable that deleting 6 months of history can take one hour (!) gives me confidence that I'll never ever go back to Firefox.
I stopped using FF when I left my previous job, synced up my bookmarks before I left but then was unable to retrieve them because I had not written down the access guid. I'll just sync with my Google account and be done with it!
> I would imagine the Firefox developers spend their time optimizing the parts of their browser that users would most likely use. I suspect that they are not terribly worried about an action that users would take (at most) once every six months.
I wish I could use that excuse at work, but it doesn't work like that.
I stopped using FF when I left my previous job, synced up my bookmarks before I left but then was unable to retrieve them because I had not written down the access guid. I'll just sync with my Google account and be done with it!
Having been a user and developer for almost any time, I would never have relied on that! A simple bookmark export, spot check for some URLs, USB drive/email/FTP to somewhere. I've always done that when leaving jobs (along with other personal things or notes/application settings).
Maybe I'm too cautious, but I've always ended up with a good copy of my data.
I still use both for cross browser testing, and at the moment I still use FF & Firebug but I am weaning myself off it. My day to day browser for everything is Chrome, in much the same way we all ditched IE but still had to occasionally use it for those sites "optimized" for IE.
The google account is pretty much the opposite of "secure". Grants access to all the things. And 2 factor auth doesn't exactly help when you computer is compromised.
FF Sync is separate and secure - but - I bet they'll change it for something more Google-like, as usual.
There are plenty of engineers still working on Projects Snappy and MemShrink who are looking directly at the metrics related to the performance problems you describe.
The places database is known to have serious performance problems, as you discovered. It is difficult to reengineer but it is being worked on.
Finally, 64 bit windows builds are not being abandoned. They are being disabled for a time until the issues with marking bugs as 64 or 32 bit and other administrative details are ironed out.
These are my own perceptions and opinions about the situation.
You'd think they'd be focused on making a better browser, clawing more market share, and cementing their presence in the browser space.
I used to use Firefox almost exclusively, but lately Chrome and Safari have filled that need. Breaking compatibility with old plug-ins might have been necessary, but it made switching a no-brainer.
I just wish they would "stick to the knitting" and make the best browser they possibly can for multiple platforms.
Sounds like it would have been quicker to uninstall and reinstall the whole thing. Crazy!
Kind of sad. Mozilla is misguided.
Let's tally the arguments so far for prioritizing 64-bit Windows development.
Pro: The Ars article lists some Win64-specific security-bug mitigation features, unclear how significant these are.
Con: The Windows PC is a declining platform, and the current 32-bit product covers all of the platform currently. There's probably a shortage open source developers working on Windows-specifics. 32-bit is much more memory-efficient. 64-bit breaks compatibility with plugins. Address space shortage will likely be covered by the tab unloading feature mentioned in the article, before it becomes an issue in practice.
Overall sounds to me like You Ain't Gonna Need It.
That must be the reason I get am getting more .NET contracts than Java ones I suppose.
The kind of contracts you have is entirely dependent on your skill set and your network. The last time I was paid to write C# code was 8 years ago.
You need cooler friends ;-)
Our consulting company does mostly Fortune 500 and DAX 30 customers.
After 5 years of almost only Java projects, most of the new contracts are coming from .NET land.
Better explained?
Again, you need cooler friends.
The ones I have keep my account manager very happy.
before? I've seen Firefox run up against the 2gb limit[1] for years.
This 4GB space is evenly divided into two parts, with 2GB dedicated for kernel usage, and 2GB left for application usage. Each application gets its own 2GB, but all applications have to share the same 2GB kernel space.
[1]: http://www.brianmadden.com/blogs/brianmadden/archive/2004/02...
It's difficult to be rising when you start at 95%.
Nevertheless a great majority of users access the Internet via a computer running Windows and it will remain the case for a long while.
When just about every PC is sold with Windows, one would expect its market share to, at least, remain constant.
"Researchers IDC and Gartner Inc. said PC shipments in the third quarter fell more than 8% from a year earlier, the steepest drop since at least 2001." ( http://online.wsj.com/article/SB1000087239639044465780457804... )
I still remember the time Mozilla developers were fighting about removing front-facing version numbers from the browser, it's also at that point I realised there are some issues with the Firefox development team all while Chrome and even Opera gained more market share.
Remember where your loyalties lay, Mozilla. I think they're starting to spread themselves too thin with wasted development of a Firefox OS and social integration. Halting 64 bit versions of Firefox for Windows for the time being might seem like a small, trivial thing, but it's not and I think it's a bad move.
You mean the Chrome which can't even be arsed to provide 64b builds on platforms where it's easy (Linux) or trivial (OSX), let alone hard (Windows) ones?
$ file /opt/google/chrome/chrome{,-sandbox} [10:47:39]
/opt/google/chrome/chrome: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, BuildID[sha1]=0x2df3f5f435cb5747ea72be922c428b9a0017cb50, stripped
/opt/google/chrome/chrome-sandbox: setuid ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, BuildID[sha1]=0xd02cf32515390b01af9aa5b1a53cd1dfb4fb7a35, strippedMysterious...
So, this is not your typical volunteer FOSS project when you're pulling in upwards of 100 million dollars a year and the standard rebuttal to people asking for bug fixes and features does not apply.
Reminds me of the mouseover text bug that Randall Munroe was requesting to get fixed for Xkcd and was met with hostility. Did they expect him to fork Firefox to make his Firefox readers see the text? It took them 7 or 8 years to roll the fix into Firefox.
https://bugzilla.mozilla.org/show_bug.cgi?id=45375 (search for Randall).
According to the Wikipedia page on Mozilla, Google gives Mozilla money considerably beyond search royalties ($5M in 2006 for example).
Every Chrome user is presumably someone using Google for search whom Google doesn't need to pay. (I doubt that makes Chrome profitable though.) I think Chrome and Android only make sense as defensive measures against Microsoft/Mozilla and Apple respectively.
In fact I'd go so far as to say it happens as soon as they get a large, stable source of funding.
While you may have a point about spreading things too thin, I would hardly call Firefox OS wasted effort. Even as a die-hard Android-user I find it some of the most fascinating and promising development going on in the mobile-sector right now.
If there is one platform I want to succeed, it's not Apple's or Google's. It's the web.
Having you entire mobile experience powered by standardized HTML, JS and APIs would be wonderful. It would also make it dead easy to provide mobile "apps" for web-sites without the need to setup huge, dedicated app-development teams, one for each "supported" platform.
I don't see Firefox OS as wasted effort. The rest of the bunch (Apple, Google, Microsoft) are just doing a mobile/touch-oriented rehash of the desktop-regime, with an added proprietary app-store.
Firefox OS on the other hand, is not getting near the attention and recognition it deserves. It's the only revolutionary mobile-platform being developed right now. It's the only platform bringing forth some new ideas.
Sometimes it saves a huge amount of effort to wait for things to mature otherwise before proceeding.
If your firefox is using more than 4gb of memory ( >2gb via LARGEADDRESSAWARE) you have other problems, and 32bit code is almost always faster than 64bit with current CPUs.
Well, the original quote said that it won't "ever see the light of day".
The irony is that one of the reasons why modern mobile OS often feel faster than desktop applications on much faster hardware is because their APIs force programmers to give up this kind of hubris. So basically, Mozilla is building FirefoxOS, which will enforce the reasonable behavior they aren't capable of themselves when in the role of an application developer.
(Source: extensive firsthand experience with performance-sensitive C/C++ development for Windows.)
I'm sure there are some use cases where it's faster, of course, but having your heap be 50-100% larger (yes, really that much, I've measured it) is pretty hard to overcome just by adding a few extra registers.
I expect this is why Java has support for using 32-bit object pointers in 64-bit mode. Features like that would probably help Firefox tremendously.
Further, raw heap size typically has marginal impact on performance; locality of reference and size of working set are far more important. It doesn't matter if your raw heap usage grows by 30% if the majority of your accesses are to the same working set of data either way.
At the same time, a well-crafted interpreter or JIT (which people seem to think is important in browsers) benefits heavily from increasing the size of the register set. Even in more typical use cases, even without aggressive optimization, speedups of 10-20% are common in moving from x86 to x86_64.
You say a larger heap has marginal impact on performance and that locality and working set size are what matter. If larger pointers make the heap bigger, then the working set is going to grow as well, and locality will be worse because the larger pointers mean less objects fit into a cache line.
If it's really a common issue with firefox's JS implementation for some reason, there's nothing to stop them from using a compressed pointer scheme for JS that uses 32b pointers and a known offset; it's a common technique. You give up one register to keep the offset around, but you've still netted 7 registers from the switch to the 64b ISA, and adding the offset is either a simple OR or can be folded into an LEA (nearly free or free).
Let's not confuse "they haven't had a chance to tune the 64b JS engine, and the 32b one has been worked on for years" with "x86_64 is slower than x86_32".
Let's also not confuse "a sufficiently smart compiler..." with real-world observed performance :)
BTW data layout transformations like compressed fields would also be useful on 32-bit. The vast majority of object graphs would be happy with 16 or even 8-bit identifiers, not to mention JS numbers which are all 64-bit floats even on 32-bit platforms.
"x86-64 is slower because pointers are larger" does not follow from "Firefox's JavaScript engine is slower and uses more memory on x86-64"
(LuaJIT also uses a limited memory arena for allocations but it's not inherent to the design; it could be changed but the current garbage collector can't handle that much data)
Considering it has 16 general-purpose registers (twice as many as x86), I wouldn't consider amd64 register-rich. It's, at best, less starved than x86 but no match for the MIPS processors from 1981.
It's really a pretty terrible idea for Mozilla to favor 32-bit code over 64-bit code these days. Not so much because of any feature or perf differences, but because it signals that they don't really have a clue what they are doing.
There are some (mostly numeric -- hand-tuned FFTs come to mind) codes for which the lack of names really does cause difficulty, but they are relatively few and far between.
All that aside, yes, 8 GPR names is just absurd, and targeting x86_32 is ridiculous when x86_64 is so widely supported.
There are several reasons for this.
First of all, web browsers are very pointer-chasing heavy because of the nature of web specs: the DOM is all about tree traversals, and so is CSS layout. Further, you have to share style, font, etc data across objects to get anything resembling sane memory usage, which means chasing pointers to all that data. Given that many of the algorithms involved require traversing large chunks of the DOM tree and various ancillary data structures, the upshot is that most of the really processing-intensive parts of a browser layout engine (possibly excluding graphics) are in fact more cache-bound than register-starved.
The second reason is a bit of a chicken-and-egg problem. Since most of the users are running the 32-bit builds, the 32-bit JIT has had more optimization work on it than the 64-bit one. The obvious solution is to improve the 64-bit JIT, of course.
The third reason is that even in JITTed code it turns out that cache locality matters a lot because JS objects share lots of their state across multiple objects so getting to it involves pointer-chasing. An actual JSObject in SpiderMonkey is 4 pointers and all the other things you want out of an object you reach through those 4 pointers. This reduces memory usage enormously compared to putting the data inline in the objects, and actually improves cache locality in general, but exacerbates the difference between 32-bit and 64-bit.
You're right that for heavily numeric JITted code x86-64 beats the pants off x86-32. Unfortunately most JS out there is object-heavy pointer-chasing, not numeric code...
I was using the 64-bit builds over at http://wiki.mozilla-x86-64.com/Firefox:Download when Adobe first kicked out a 64-bit beta of Flash. Later I switched to the official Nightly builds when they went 64-bit.
Unfortunately I'm not able to offer much insight into if it was better. Aside from a couple of short strings of bad builds that caused crashes I never had any issues with them.
X) http://en.wikipedia.org/wiki/64-bit#64-bit_processor_timelin...
Software shipping as 32-bit isn't a bad thing. It means it will run on more machines. Shipping a Windows application as 32-bit has NO negative consequences unless your application needs more than 2GB of available address space, with a couple rare exceptions like shipping device drivers or debugging tools.
(A few years ago I had to run Safari in 32-bit mode to test unity web apps for the brief period where unity didn't offer a 64-bit plugin.)
What do you base those statements on? I changed to 64 bit at Windows XP, never looked back and stayed there on multiple machines through Vista, Win7 and now win8.
Windows Server 2008 R2 and Server 2012 are both 64 bit only. There are no 32-bit builds of these OSs.
Where is the "complete fuck-up"?
Consider this, most default builds (even the cheap ones) come with at least 4GB of RAM nowadays. The only machines I see with less RAM now are nettops, netbooks and other miniaturized builds. You need 64-bit Windows to fully take advantage of 4GB (with 32-bit Windows, you'll only see like 3.something), not to mention anything larger than 4GB is essentially worthless to a 32-bit OS. Dell isn't going to sell you a laptop advertised with 6GB RAM and then stick a 32-bit version of Windows on there that can only use <4GB.
(Now, this 4GB limit to 32-bit OS's isn't a problem with PAE. But why Windows has support for PAE but nobody seriously uses it is a story I don't know the details to.)
[1] https://groups.google.com/d/msg/mozilla.dev.apps.firefox/jpX...
Gnome 3 is not the same thing, as Gnome 3 is just a window manager, based on the same X, the same APIs and the same GTK, just as Unity and Gnome 2.
I just wanted to check something on the internet and now is when you decide to stop and delay the user?
This is an old problem. Chrome solved it the right way by stepping out of the startup/shutdown dichotomy and doing everything in background. Just one of the many areas where Google ran circles around Mozilla (with the benefit of moving from a clear slate, and probably also of staying away from the Gecko clusterf*ck).
Yesterday I ran into a 5 year old bug in Firefox (https://bugzilla.mozilla.org/show_bug.cgi?id=405761) that required me to write Firefox-specific JavaScript workarounds. I used to accept that from IE, but from Firefox, never.
As a conclusion, it is not surprising at all that Mozilla is focusing on developing products that do not compete with Google's browsers and other software.
All Google needs is search results to show advertisements on and a browser capable of running their applications. Both Firefox and Chrome meet this requirement.
You forget that Google pays Mozilla a lot of money for something they can get for free every time a Chrome installation replaces a Firefox installation. So the potential savings for Google is (currently) $300M/year once they have killed off Firefox completely.