Firefox is Going 64-bit - What Should We Expect?

[Tharic-Nar]

With a lot of the software we use on a daily basis going 64-bit, isn't it about time that our Web browsers catch up? While it's not of utmost importance from a performance perspective to go 64-bit (it's just a Web browser, after all), there's little reason not to go in that direction - especially when plugins, such as Flash and video decoders, are available in 64-bit flavors.

You can read the rest of our post and discuss here.

 

[Doomsday]

Haell! Its Aboaut taime!

 

[On_Wisconsin]

yay...

 

[marfig]

>> What Should We Expect?

1. Other than what was discussed, if the application makes use of all the native datatypes for 64 bit systems, there could be a significant increase in memory footprint. However this can be optimized. While a 64bit integer should theoretically be default integer datatype, it isn't required for most uses, for which reason int32 should be used. Because 64bit compilers for the Unix, Windows and OSX worlds all make use of a data model that retains int as a 32bit sized variable, this shouldn't be a problem at all.

There should be however still an increase in memory footprint (there not being one would be a sure sign Firefox wasn't true 64bit). This is because, other than datatypes, memory pointers are no longer 32bit in size, but 64bit. Pointers are very prevalent constructs since they hold the address of memory locations. They are however somewhat volatile, with many being constructed just to point to a memory location to help perform some operation, and then discarded. So, while this indicates an increase in memory consumption, it's not anything to be much concerned about.

2. There should be a somewhat recognizable performance increase. Particularly under load. Not really because 64bit is faster than 32bit (under no circumstance it is), but because 64bit applications perform better than 32bit application under a 64bit-ready operating system. This is so because there are no memory address translations, no operating system subsystem performing extra work, no unnecessary datatype castings, no nothing. A 64bit application is expected to perform under a 64bit operating system, as a 32bit application would on a 32bit system.

There are exceptions to this. Certain types of 64bit applications do perform better in 64bit OSes than 32bit ones on a 32bit OS. This is almost always true of any application that makes intensive use of the CPU because it can take advantage of the larger CPU registers. And even more if they also make use of multi-threading. They can just move more data to the CPU. Encryption and compression algorithms are an example. Performance critical applications like weather prediction, scientific simulators, distributed computing software, etc are another.

This shouldn't benefit much applications that make nominal use of the CPU though, as is the case with a browser. Think of it has having a 4 lane highway. If only 1,000 cars pass there in an hour, making it an 8 lane won't get anyone anywhere faster. But if 100,000 cars want to make that highway every hour, well then...

Another factor is the application usage pattern. Because a browser usage pattern is event-driven (users presses things, and things happen that take up to a couple seconds, after which things wait to be pressed again), performance benefits from larger CPU registers go unnoticed (except of course for anyone on a placebo diet). If however the operations took a lot longer to compute, or a browser wasn't an event-driven application but something that would perform continuously on its own, then those benefits would become visible.

 

[Kayden]

I'm okay with this but seriously the memory leak and other crap needs to be addressed first.

Your right Marfig, the next question is will this make it more difficult for those who create Add-ons more difficult (which it probably will) and will Mozilla try to support those working on them? That I think will make or break the 64bit browser because I don't know anyone who doesn't use at least 3 or 4 Add-ons for FF.

 

[marfig]

I honestly don't know.

For Firefox extensions, I suspect very few need to actually change if all they are using is javascript and XUL (which are the vast majority). Javascript language specification ignores computer architecture. It's up to the javascript interpreter to care about that and this one ships with the browser. XUL is a markup language and as such also entirely architecture agnostic. All other technologies involved in extension creation are also ignorant of any architecture issues.

More complex extension may need to change. Extensions that make use of out-of-process java could require 64bit Java, or maybe not because on this case Java runs on a entire different process from that of Firefox and never interfaces with it. I never delved into Firefox extensions. So i'm just speculating here.

Plugins... well, these will almost surely need to go 64bit. I think they interface with Firefox at a deeper level.

What's curious however is that technically there should be no impediment to run 32 bit everything in a 64 bit browser like Mozilla. It will all depend on how much they won't to enforce 64bit plugins. It's just that they must not forget that what will definitely be impossible to run is 64bit plugins on a 32 bit browser. So, the 64 bit browser will segment the plugins ecosystem and some of the more advanced extensions. Whether the makers of these are willing to support two versions of their plugins or extensions, is a matter of debate. I suspect many are not.

EDIT:

You are dead on on memory leaks. All this will be pretty useless if all they are going to do is to port the current code base to 64bit and bringing with it that mess of code that has been Firefox memory management. And with pointers being twice as big as they were in the 32bit browser, memory leaks would be... let's say "much larger", although this is one of those few cases where an hyperbole could be more accurate.

 

[Kougar]

My question would be the 64bit plug-ins... I tried using the 64bit builds of Java and Flash, but they only work with a 64bit browser. And a 64bit browser can't use 32bit plugins.

Other programs on my system had trouble using them, and some site plugins didn't work with them at all. I'd presume it would be a pretty rocky start until more of the online industry migrated to supporting 64bit plugins... It was fun to play with but I quickly got tired of the 64bit browser running into issues, not to mention having two copies of flash & java installed concurrently. I'll be sticking with 32bit browser apps in my 32bit browser in a 64bit OS for a few more years I think..

The memory footpint issue is a good question... I'd be curious to see more detailed testing on that, and not just for browsers either. The last time I saw a comprehensive 32bit vs 64bit OS memory footprint comparison was with Vista, when the drivers and programs used were at fault more than the OS itself...

 

[marfig]

Personally, I think the 64bit take-over is long due. But this isn't a new process. 32bit adoption was a slow process too (more than 10 years to become a de facto standard in both business and consumer markets) -- and if you consider 32bit was actually much more needed at the time than 64bit is today, this may help illustrate why 64bit is taking its time too. In fact, considering that 64bit was really only introduced around 2004, we aren't that far into it yet and probably just starting a long haul.

But a revolution would be nice. Or a change of pace, helped by an influential Something or Someone forcing adoption by stopping 32bit support. What would we gain from it? Well, that's the problem. Not much really, since at the end of the day the vast majority of us need 64bit computing as much as we need an extra pair of lungs. The only real driving force behind 64bit adoption has been hype. Which is fine and all, but its still a whole lot of nothing.

What drives me insane is the waiting. Because it complicates tremendously software development as companies and individuals eventually feel forced to support two branches of their code base and all the grief that usually comes with that (with this browser issue being just one of many examples). 64bit is inevitable whether most people actually need it or not. I'd rather have it over and done with, than witnessing this limbo for the past 7 years.

The memory footpint issue is a good question... I'd be curious to see more detailed testing on that, and not just for browsers either.

This is something I suppose I could do by writing a small use case application that demonstrates a typical memory usage scenario in most applications and have it ported to both 32bit and 64bit.

Other than that, I'm currently running a 32bit system. A few of us could organize ourselves to come up with a testing strategy for one or more applications with 32bit and 64bit ports, produce some detailed results and make of it what we will.

 

[Glider]

I compile firefox on my 64 bit system since the ice ages... well, at least for years

 

[Kougar]

I'd disagree on that point, Marfig. I'd counter that the driving force for 64bit Windows adoption has been consumers wanting to access more than 3.2GB of system memory.

Lets say someone is using XP or Windows 7 32bit, and they have 4GB of RAM. At most they'd really have 3.2GB. But that's not considering the GPU... Using a GPU with 1GB of VRAM means at best they only can use 3GB... if that GPU happened to have 2GB of RAM, that would actually leave the OS with HALF of that 4GB of RAM to work with, technically less because other hardware requirements further subtract from the total.

Given the prevalence of 1.5-2GB VRAM graphics cards (especially on midrange laptops), the 64bit adoption almost didn't happen soon enough. So depending on what GPU a person is running, it is very possible they could actually gain RAM from switching to a 64bit OS even if they only have 4GB of system memory.

 

[marfig]

Yeah. I'm a bit critic of the 64bit emergence, I concede. I just don't see where exactly are the >3.6 GB requirements for most consumers. And this includes gaming machines.

For those that do have that requirement... sure. But much of the rest have been caught up in the more-is-better fallacy, without realizing they don't ever make any concrete use of that extra-memory. It's just sitting there.