Mozilla quietly kills Firefox 64-bit for Windows(thenextweb.com)
thenextweb.com
Mozilla quietly kills Firefox 64-bit for Windows
http://thenextweb.com/apps/2012/11/22/mozilla-quietly-kills-firefox-64-bit-for-windows-despite-an-alleged-50-of-testers-using-it/
8 comments
https://news.ycombinator.com/item?id=4817574
I use Pale Moon 64-bit, custom-built and optimized Firefox clone: http://www.palemoon.org/
Hm, I use waterfox -- and it seems to be a little better updated?
http://www.waterfoxproject.org/
http://www.waterfoxproject.org/
Wow, just tried that and it is surprisingly fast. Wasn't expecting to notice a difference, but I did. Running on a Windows 8 x64, SSD drive, 1.7GHz i7.
...for Windows Operating Systems.
Firefox is natively 64bit on Linux and OSX already.
So? I replied to a comment about Pale Moon (not Firefox, which I'm obviously using), so you might wanna take your downvote back.
From their website: "A custom-built and optimized Firefox-based browser for Windows"
From their website: "A custom-built and optimized Firefox-based browser for Windows"
This just reeks of dumb. Seriously guys, support 64 bit platforms or perish.
They do support 64 bit platforms. With 32 bit binaries.
If you have no need for more than 3gb of memory per process then 32 bit is a great choice. The pointers being half size is a non-trivial memory saving.
I'd be happy if windows would let you use something like the x32 build target that linux got recently for extra registers though.
If you have no need for more than 3gb of memory per process then 32 bit is a great choice. The pointers being half size is a non-trivial memory saving.
I'd be happy if windows would let you use something like the x32 build target that linux got recently for extra registers though.
There will be a memory saving but the loss of access to better instructions and the registers would surely cost you some performance overall (may be benchmark and processor dependent)
32-bit processes can get 4GB of memory on 64-bit Windows: http://msdn.microsoft.com/en-us/library/windows/desktop/aa36...
I thought the limit was 2GB, which Firefox is getting dangerously close to. 4GB gives a lot more wiggle room, but I wonder how long it will last...
I thought the limit was 2GB, which Firefox is getting dangerously close to. 4GB gives a lot more wiggle room, but I wonder how long it will last...
I'd rather not have to pollute a pure 64-bit install with a whole bunch of 32-bit libraries to run just one 32-bit app though. It's adds even more headache keeping those patched and up to date.
remember that we are talking windows here. which libraries do you have to patch for firefox (i.e. those they do not ship and which are not in the core win os)?
The problem is you need almost-contrived situations to notice these kinds of improvements, and a web browser deals with way too much I/O to fit into this category.
Have you noticed any tangible benefit to using a 64-bit build over a 32-bit one? Performance of the current x64 builds as measured by responsiveness and javascript benchmarks is about on-par with the 32-bit version for most things; the performance and even compilation of plugins is however another matter entirely and the reason for using Firefox for me over another solution is almost always the plugins available.
I have been using PaleMoon builds and from what I gather the source tree is not being tombstoned, just the nightly builds. [0]
The reasons given for crashes (driver/component out-of-tree bugs) make sense but I'm not really involved in the development or testing so I'm sure others will have better input.
[0] http://forum.palemoon.org/viewtopic.php?f=15&t=1700
I have been using PaleMoon builds and from what I gather the source tree is not being tombstoned, just the nightly builds. [0]
The reasons given for crashes (driver/component out-of-tree bugs) make sense but I'm not really involved in the development or testing so I'm sure others will have better input.
[0] http://forum.palemoon.org/viewtopic.php?f=15&t=1700
Let me just say something
"Microsoft Windows XP Professional x64 Edition released on April 25, 2005" http://en.wikipedia.org/wiki/Windows_XP_Professional_x64_Edi...
7 years.
Go to a store, see what kind of Windows is being shipped, if it's 32 or 64bits.
If there's one version that has to be discontinued that version is the 32-bit version.
Linux as well suffers with lack of 64-bit versions, it seems Mozilla started shipping them the other day (and is not very promoted)
Computers already ship with more than 4GB memory.
Leave 32-bit, it's been enough time already.
"Microsoft Windows XP Professional x64 Edition released on April 25, 2005" http://en.wikipedia.org/wiki/Windows_XP_Professional_x64_Edi...
7 years.
Go to a store, see what kind of Windows is being shipped, if it's 32 or 64bits.
If there's one version that has to be discontinued that version is the 32-bit version.
Linux as well suffers with lack of 64-bit versions, it seems Mozilla started shipping them the other day (and is not very promoted)
Computers already ship with more than 4GB memory.
Leave 32-bit, it's been enough time already.
> Linux as well suffers with lack of 64-bit versions,
Only in commercial or prop software
Only in commercial or prop software
When you pay for memory on a monthly basis, economizing on it may be a good idea:
http://journal.dedasys.com/2008/11/24/slicehost-vs-linode
http://journal.dedasys.com/2008/11/24/slicehost-vs-linode
Don't compare the Virtual Size of process. This is not how it works. And yes, running x64 on my Linode/
Also, see the limitations of MongoDB and Go for example, in 32-bit systems, they are very relevant.
Also, see the limitations of MongoDB and Go for example, in 32-bit systems, they are very relevant.
I look at RSS in those numbers too, and they're lower on 32 bit systems, obviously, That is how it works.
I'm not interested in MongoDB in the slightest, and while Go looks pretty cool, I'll wait for it to mature.
I'm not interested in MongoDB in the slightest, and while Go looks pretty cool, I'll wait for it to mature.
Sure, still, what really affects memory usage is data, not programs.
So if memory is an issue in 64-bits, most likely it will be an issue as well in 32-bit. In some cases it may make a difference, but they're not that common.
Even EC2 Micro supports 64-bits now
Sure, 64-bit uses more memory, like 32-bit use more memory than 16-bit, or like programs in ARM (and maybe Thumb) take more space than programs in x86
So if memory is an issue in 64-bits, most likely it will be an issue as well in 32-bit. In some cases it may make a difference, but they're not that common.
Even EC2 Micro supports 64-bits now
Sure, 64-bit uses more memory, like 32-bit use more memory than 16-bit, or like programs in ARM (and maybe Thumb) take more space than programs in x86
You run Firefox on a VPS?
Itanium is the future.
Mozilla seems, at least to me, to be becoming more and more like the GNOME project. It's projecting a constant stream of unusual, if not outright bad, ideas and actions.
The Firefox version numbering debacle, including the constant problems it caused for extensions, was just plain silly.
Then there's Firefox Mobile. I've always found it very inferior to the other commonly-available mobile browsers. Aside from trying it out briefly, there was no reason to continue using it. This is probably the same for others, and likely why its uptake basically hasn't happened at all.
Earlier this year they seem to have withdrawn their interest in Thunderbird, which is by far one of their better offerings.
More recently, there's been a lot said about Firefox OS. There's a very good chance that this will become an unused, uninspiring, generally-ignored product, much like Firefox Mobile.
And now there's this decision.
Redirecting effort away from applications that are actually used, like Firefox and Thunderbird, toward things that clearly have little to no future, like Firefox Mobile or Firefox OS, just doesn't make sense.
The Firefox version numbering debacle, including the constant problems it caused for extensions, was just plain silly.
Then there's Firefox Mobile. I've always found it very inferior to the other commonly-available mobile browsers. Aside from trying it out briefly, there was no reason to continue using it. This is probably the same for others, and likely why its uptake basically hasn't happened at all.
Earlier this year they seem to have withdrawn their interest in Thunderbird, which is by far one of their better offerings.
More recently, there's been a lot said about Firefox OS. There's a very good chance that this will become an unused, uninspiring, generally-ignored product, much like Firefox Mobile.
And now there's this decision.
Redirecting effort away from applications that are actually used, like Firefox and Thunderbird, toward things that clearly have little to no future, like Firefox Mobile or Firefox OS, just doesn't make sense.
I think when you make such a damning post as this, you're required to make sure all opinions are current and factual. I mostly talk about what seems to be a clearly outdated opinion of Firefox for Android (Mobile) which is widely regarded as one of the best mobile browsing experiences around. Though each to their own.
The Firefox versioning change was naive. It was rushed and a lot of work that should've taken place prior to the change was done afterwards and it remains to be seen just whether or not they'll ever truly pick up all the pieces from that. The negative word of mouth about extensions breaking is out there.
There is no excuse for the demise of Thunderbird. It remains to be a short sighted decision. But in that regard, Mozilla never really had the same ambitions as Opera. Mozilla should've been approaching the likes of HTC and Samsung and offering to provide the browser and mail experience rather than Google.
As for Firefox OS/B2G, I'd say it's highly probable that it'll fall by the wayside. Despite the resources thrown behind it. It's just not going to be a viable competitor. When you think about the sheer amount of money and effort thrown behind the likes of Android, iOS and Windows Phone, what exactly are Mozilla hoping for? It's only served to slow down development of features and other products that could serve the greater Mozilla community.
The Firefox versioning change was naive. It was rushed and a lot of work that should've taken place prior to the change was done afterwards and it remains to be seen just whether or not they'll ever truly pick up all the pieces from that. The negative word of mouth about extensions breaking is out there.
There is no excuse for the demise of Thunderbird. It remains to be a short sighted decision. But in that regard, Mozilla never really had the same ambitions as Opera. Mozilla should've been approaching the likes of HTC and Samsung and offering to provide the browser and mail experience rather than Google.
As for Firefox OS/B2G, I'd say it's highly probable that it'll fall by the wayside. Despite the resources thrown behind it. It's just not going to be a viable competitor. When you think about the sheer amount of money and effort thrown behind the likes of Android, iOS and Windows Phone, what exactly are Mozilla hoping for? It's only served to slow down development of features and other products that could serve the greater Mozilla community.
> things that clearly have little to no future, like Firefox Mobile or Firefox OS, just doesn't make sense.
Firefox OS has to be the most exciting thing they're doing. Why does it not have a future?
Firefox OS has to be the most exciting thing they're doing. Why does it not have a future?
Because a lot of people don't give a bear about Firefox OS.
A lot of people do.
It isn't officially released yet, so of course it's not going to be as popular as a released product. Android wasn't popular until acquired and pushed by Google.
It isn't officially released yet, so of course it's not going to be as popular as a released product. Android wasn't popular until acquired and pushed by Google.
Who does? Tell me of the millions and millions of users out there waiting in anticipation of Firefox OS? Firefox decide to kill off around half of their Nightly (read most diehard users) and expect to carry that good faith over to what? Firefox OS? Are you going to convince the 30 million people that bought a Samsung Galaxy S3 that all of a sudden, the brand they bought into isn't actually important and that they should jump on the Firefox OS train? It's unrealistic.
I used to use mainly Chrome and Firefox, but after moving to Windows 8 (I have to because I write some Windows 8 stuff) 64-bit, Firefox often hangs after opening, hangs after opening tabs, hangs after loading pages, etc.. I switched to using Safari as browser B, and I don't think that is even still official for Windows...
Why not Chrome?
I do use Chrome. I need a second concurrent browser for various reasons.
You can have multiple concurrent Chrome browsers, if you use the multi-user feature, detailed here:
http://support.google.com/chrome/bin/answer.py?hl=en&ans...
http://support.google.com/chrome/bin/answer.py?hl=en&ans...
Ah, I misunderstood, thanks. I'd recommend Opera!
+1 Opera is so underrated.
Posted from Opera.
Posted from Opera.
There was never a 64-bit version of Firefox. There were 64-bit Nightly builds, which aren't even branded as Firefox. Running them because you wanted a 64-bit version of Firefox would have been a silly thing to do, because, as unreleased software, they also crash significantly more frequently than released Firefox versions, which almost certainly would have killed any productivity increase from running a 64-bit version of Firefox.
The big question is, why won't 64 bit catch on? Too new? I had a 64 bit chip 10 years ago and most of you probably did too. Too expensive?
It's a good question and it probably comes down to programmers and habit. Multi core processing and async/multithreading are finally starting to take hold but optimizing for a 64 bit bus still seems like an afterthought.
I am asking seriously because I don't have a definitive answer, but why is it just not catching on?
It's a good question and it probably comes down to programmers and habit. Multi core processing and async/multithreading are finally starting to take hold but optimizing for a 64 bit bus still seems like an afterthought.
I am asking seriously because I don't have a definitive answer, but why is it just not catching on?
Never underestimate human apathy. A super majority of the world does not care for progress, if it means having to change even the most nominal of habits. Not even for sometimes massive benefits. In fact, a great many individuals will become extremely vocal if you try and force something as tiny as "picking one file extension for a file type instead of using two like we have in the past."
The only way things advance are when walls are finally hit. With 16-bit, this was trivial: the limitations were crippling. It'll get there with 32-bit, as applications begin to crash with the ~2GB per process memory limitations on Windows, and PCs continually appear with far more than 8GB of RAM available. But I'd say we are probably 5-10 years off from a point where we could consider deploying a 64-bit only application without losing users.
The only way things advance are when walls are finally hit. With 16-bit, this was trivial: the limitations were crippling. It'll get there with 32-bit, as applications begin to crash with the ~2GB per process memory limitations on Windows, and PCs continually appear with far more than 8GB of RAM available. But I'd say we are probably 5-10 years off from a point where we could consider deploying a 64-bit only application without losing users.
What you say is often true. Take Windows XP vs Windows 7; Windows 7 is miles ahead in the security department, that should be a killer reason for people to upgrade. Or IPv4 vs IPV6 for obvious reasons.
But 64-bit has none of these big advantages in practice. Battery life on OS X was worse right after the switch.[1] I have downloaded Podcasts a year before iTunes ran in 64-bit mode and they stopped working with the switch (nothing obscure - early Railscasts episodes). Many perfectly fine machines have been marked obsolete by Apple because their processors or graphics drivers weren't 64bit. - Windows has been a mess for me too: the 64-bit ODBC control panel is in system32 and the 32-bit ODBC control panel is in WoW64.[2] Because there are no fat binaries, casual users suddenly need to know which version of a Windows program to download. - So there is a lot of friction that needs to be outweighed. For what? - If Firefox wants to escape the 2GB barrier, the wiser choice might be to use one process per tab, as other browsers do.
If you look at the first and last sentence of your posting, you are basically accusing people of apathy because they keep using their 32-bit computers.
[1] http://forums.appleinsider.com/t/104687/64-bit-safari-reduce... (might also be caused by API changes that Apple has tied to the 64-bit platform) [2] http://robertoschiabel.wordpress.com/2008/02/28/windows-x64-...
But 64-bit has none of these big advantages in practice. Battery life on OS X was worse right after the switch.[1] I have downloaded Podcasts a year before iTunes ran in 64-bit mode and they stopped working with the switch (nothing obscure - early Railscasts episodes). Many perfectly fine machines have been marked obsolete by Apple because their processors or graphics drivers weren't 64bit. - Windows has been a mess for me too: the 64-bit ODBC control panel is in system32 and the 32-bit ODBC control panel is in WoW64.[2] Because there are no fat binaries, casual users suddenly need to know which version of a Windows program to download. - So there is a lot of friction that needs to be outweighed. For what? - If Firefox wants to escape the 2GB barrier, the wiser choice might be to use one process per tab, as other browsers do.
If you look at the first and last sentence of your posting, you are basically accusing people of apathy because they keep using their 32-bit computers.
[1] http://forums.appleinsider.com/t/104687/64-bit-safari-reduce... (might also be caused by API changes that Apple has tied to the 64-bit platform) [2] http://robertoschiabel.wordpress.com/2008/02/28/windows-x64-...
64-bit binaries net me a 15% performance increase with my application. Obviously it can vary per application, and depends on where the bottlenecks are. It's been my experience that x86->amd64 is often beneficial: the x86 is so register starved that it makes up for the larger pointers, and most of the latter is mitigated through 32-bit relative instructions. Now PowerPC, sure. 32-bit PPC code does tend to run faster than 64-bit from my experience.
The other advantage is being able to utilize more than 2GB of memory per process. The reason to favor pure 64-bit is to get rid of all that extra 32-bit compatibility code. WoW64, in this case, or ia32libs on Linux.
Whether you're pragmatic about it or not, 32-bit will eventually go away. I'd prefer to see it sooner rather than for it to drag on for decades like IPv6.
And yeah, WoW64 is a clusterfuck. Basically, Microsoft wanted to make porting 32-bit applications as easy as possible. Since some applications may have been hardcoded to System32, they stuck the 64-bit libraries there, and put the 32-bit ones in WoW64. They also cloned the registry so you actually have 32-bit and 64-bit keys (see KEY_WOW64_32KEY flag.) What can I say? Microsoft's always had a thing for rigid backward compatibility at the expense of common sense design. But they are still the market leader, so I guess they know a thing or two :/
I don't care for your Firefox example. What if one single tab needs >2GB, like say a really high-end WebGL game? What about other applications? People found similar tricks for getting more memory in 16-bit processes too (far pointers), but we aren't still using Win16.
I'm accusing people of apathy because they resist change simply because it's change. I get being pragmatic, but at some point we have to cut ties with the past. Even Microsoft understands this, as you can no longer run 16-bit applications on the latest versions of Windows.
The other advantage is being able to utilize more than 2GB of memory per process. The reason to favor pure 64-bit is to get rid of all that extra 32-bit compatibility code. WoW64, in this case, or ia32libs on Linux.
Whether you're pragmatic about it or not, 32-bit will eventually go away. I'd prefer to see it sooner rather than for it to drag on for decades like IPv6.
And yeah, WoW64 is a clusterfuck. Basically, Microsoft wanted to make porting 32-bit applications as easy as possible. Since some applications may have been hardcoded to System32, they stuck the 64-bit libraries there, and put the 32-bit ones in WoW64. They also cloned the registry so you actually have 32-bit and 64-bit keys (see KEY_WOW64_32KEY flag.) What can I say? Microsoft's always had a thing for rigid backward compatibility at the expense of common sense design. But they are still the market leader, so I guess they know a thing or two :/
I don't care for your Firefox example. What if one single tab needs >2GB, like say a really high-end WebGL game? What about other applications? People found similar tricks for getting more memory in 16-bit processes too (far pointers), but we aren't still using Win16.
I'm accusing people of apathy because they resist change simply because it's change. I get being pragmatic, but at some point we have to cut ties with the past. Even Microsoft understands this, as you can no longer run 16-bit applications on the latest versions of Windows.
No doubts about the advantages of x86_64, I would insist on it in a new computer for virtualisation and encoding DVDs. But many people don't do much more on their computers than they can do on their highly restricted armv7 gadgets. Desktop software has reached a plateau IMHO, I don't think we can extrapolate from the 16->32 bit change. Gamers and IT professionals are a completely different beast of course.
How do you know that people hate change? Has anyone ever said "no, I don't want to run a 64-bit program, I've always been a 32-bit person"? People have to endure the crap in my grandparent post and that is what they hate and resist, especially if there is no tangible benefit to it. SSDs have entered the mainstream market much later and I have seen nothing but praise for them. SSDs are change too, often a painful one for a running system, but they solve an obvious problem.
How do you know that people hate change? Has anyone ever said "no, I don't want to run a 64-bit program, I've always been a 32-bit person"? People have to endure the crap in my grandparent post and that is what they hate and resist, especially if there is no tangible benefit to it. SSDs have entered the mainstream market much later and I have seen nothing but praise for them. SSDs are change too, often a painful one for a running system, but they solve an obvious problem.
I do not agree with your pessimistic argument regarding human nature.
A much bigger issue is that migrating a massive 32-bits application to 64-bits requires too much effort, because unfortunately the C and C++ specifications have left a ton of flexibility and room for platform-specific behavior.
For instance it's beyond me why those specs haven't mentioned details like concrete sizes for really basic datatypes, like Ints and Chars, especially since development in C and C++ tends to get into really low-level details and optimizations, which means you end up relying on Ints being 4 bytes in size (how could you not do that?). The truth really is that even seemingly unimportant details such as the size of Ints can mean the difference between a rock-solid 32-bits app and a 64-bits app that's broken almost beyond hope of ever being fixed.
If anything, this should be the number one reason for why we must stop using C and C++ for new application developments and even in systems/embedded programming we could do a lot better, as these languages are unsuitable for continued improvements due to Moore's law, impeding progress.
Can you see how this creates a vicious circle btw? So we can have affordable consumer workstations with more than 10 GB of RAM right now with multiple cores and all that, which makes client-side development in garbage-collected functional programming languages feasible, but we can't really go there because the 32-bits legacy is holding us back. That's funny and goes to show that sometimes Worse is Not Better.
A much bigger issue is that migrating a massive 32-bits application to 64-bits requires too much effort, because unfortunately the C and C++ specifications have left a ton of flexibility and room for platform-specific behavior.
For instance it's beyond me why those specs haven't mentioned details like concrete sizes for really basic datatypes, like Ints and Chars, especially since development in C and C++ tends to get into really low-level details and optimizations, which means you end up relying on Ints being 4 bytes in size (how could you not do that?). The truth really is that even seemingly unimportant details such as the size of Ints can mean the difference between a rock-solid 32-bits app and a 64-bits app that's broken almost beyond hope of ever being fixed.
If anything, this should be the number one reason for why we must stop using C and C++ for new application developments and even in systems/embedded programming we could do a lot better, as these languages are unsuitable for continued improvements due to Moore's law, impeding progress.
Can you see how this creates a vicious circle btw? So we can have affordable consumer workstations with more than 10 GB of RAM right now with multiple cores and all that, which makes client-side development in garbage-collected functional programming languages feasible, but we can't really go there because the 32-bits legacy is holding us back. That's funny and goes to show that sometimes Worse is Not Better.
It isn't about human apathy, it's about not fixing what isn't broken. You sometimes come across stories of a windows 3.1 machine controlling a critical piece of machinery for a business.
As for C and C++, the bugs that prevent a program going from 32-bit to 64-bit is making assumptions about the sizes of datatypes, and these days is usually seen as bad programming. They are just tools though, and have their uses, even in a multi-threaded world.
As for C and C++, the bugs that prevent a program going from 32-bit to 64-bit is making assumptions about the sizes of datatypes, and these days is usually seen as bad programming. They are just tools though, and have their uses, even in a multi-threaded world.
> these days is usually seen as bad programming
I've seen this repeatedly told again and again, however people saying that don't really know what they are talking about - it's extremely easy to make assumptions without even realizing you're making one, even if you could recite the whole spec of C and C++.
Even more, in C and C++ it is inevitable to make assumptions, even with eternal vigilance. I want you to point to a single reasonably big application that doesn't make such assumptions. And please don't point to one that works on both 32-bits and 64-bits, as in those cases the assumption about Ints simply evolved to: either 4 bytes or 8 bytes, with some awful code out in the wild that only works because of conditional compilation ... sometimes I wonder how software I rely upon works at all.
I've seen this repeatedly told again and again, however people saying that don't really know what they are talking about - it's extremely easy to make assumptions without even realizing you're making one, even if you could recite the whole spec of C and C++.
Even more, in C and C++ it is inevitable to make assumptions, even with eternal vigilance. I want you to point to a single reasonably big application that doesn't make such assumptions. And please don't point to one that works on both 32-bits and 64-bits, as in those cases the assumption about Ints simply evolved to: either 4 bytes or 8 bytes, with some awful code out in the wild that only works because of conditional compilation ... sometimes I wonder how software I rely upon works at all.
Well the biggest thing you need to do is not use ints to store pointers, and use things like size_t, etc. This accounts for the majority of C programming bugs when moving from 32 bits to 64 bits.
As for making assumptions, this is only natural, and programmers should be aware of the basic differences so they can correct their assumptions.
As for making assumptions, this is only natural, and programmers should be aware of the basic differences so they can correct their assumptions.
The big question is, why won't 64 bit catch on?
I suppose the obvious response is “Why should it?”
It makes a lot of sense to have a 64-bit operating system if we have, for example, more than 4GB of memory to work with. However, unless a single process needs access to the same scale of resources all on its own, there isn’t necessarily any advantage to writing things like application code the same way.
Moreover, moving to 64-bit pointers means more memory is required for data structures and for assembly level instructions that use indirection. In both cases, there is the potential for a significant performance hit, for example if less information fits into a cache.
OK, what about using 64-bit instructions that let us calculate with larger values? Again, that might be useful in some contexts, but on PC processors we’ve had specialist instructions for things like double-precision floating point calculations or operating over multiple bundled values simultaneously for a long time, so there are only limited benefits to be had.
Of course, set against all of these ambiguous benefits is the fact that porting to 64-bit can take a lot of work if the original code, data structures, file formats and so on were not designed with portability in mind. And once you’ve ported, if you’re also running a 32-bit version, now you have more testing to do, any related software might have to speak two protocols/APIs to remain compatible with both, etc. (This seems to be one of the main underlying points in the cited article.)
Looking at the astronomical memory requirements for something like browsers opening multiple tabs these days, perhaps in the case of Firefox there really is an argument for supporting more than 4GB of RAM. On the other hand, even modern web pages full of large images and multimedia wizardry usually only come in at ~100kB or maybe ~1MB, so even with dozens of tabs open, you need to be doing an awful lot behind the scenes to be in any danger of hitting a 4GB limit. Presumably the Mozilla folks don’t expect this to be a problem.
I suppose the obvious response is “Why should it?”
It makes a lot of sense to have a 64-bit operating system if we have, for example, more than 4GB of memory to work with. However, unless a single process needs access to the same scale of resources all on its own, there isn’t necessarily any advantage to writing things like application code the same way.
Moreover, moving to 64-bit pointers means more memory is required for data structures and for assembly level instructions that use indirection. In both cases, there is the potential for a significant performance hit, for example if less information fits into a cache.
OK, what about using 64-bit instructions that let us calculate with larger values? Again, that might be useful in some contexts, but on PC processors we’ve had specialist instructions for things like double-precision floating point calculations or operating over multiple bundled values simultaneously for a long time, so there are only limited benefits to be had.
Of course, set against all of these ambiguous benefits is the fact that porting to 64-bit can take a lot of work if the original code, data structures, file formats and so on were not designed with portability in mind. And once you’ve ported, if you’re also running a 32-bit version, now you have more testing to do, any related software might have to speak two protocols/APIs to remain compatible with both, etc. (This seems to be one of the main underlying points in the cited article.)
Looking at the astronomical memory requirements for something like browsers opening multiple tabs these days, perhaps in the case of Firefox there really is an argument for supporting more than 4GB of RAM. On the other hand, even modern web pages full of large images and multimedia wizardry usually only come in at ~100kB or maybe ~1MB, so even with dozens of tabs open, you need to be doing an awful lot behind the scenes to be in any danger of hitting a 4GB limit. Presumably the Mozilla folks don’t expect this to be a problem.
What about WebGL? It's catching on, and that means that we could see huge memory usage in a small number of tabs. I'm thinking we'll see 3d games become popular relatively quickly.
Gamers tend to have tons of tabs in their browsers. Couple this with tons of game resources and we have a serious memory hog.
Gamers tend to have tons of tabs in their browsers. Couple this with tons of game resources and we have a serious memory hog.
This sounds like a chicken-and-egg problem somewhat specific to Mozilla. Their users depend on a large stable of independently developed plugins, which must be updated to support a 64-bit Windows browser. I can imagine that many of those plugin developers are much less motivated to do the requisite porting (or fix 64-bit bugs after they port) before Mozilla ships (or even commits to shipping) a 64-bit Windows browser. But when plugins used by 80%+ of your userbase are nonexistent or buggy, releasing a browser becomes difficult: Everyday users will assume it's buggy because they don't make the distinction between plugin authors and Mozilla.
Why can't Firefox's plugincontainer marshall the calls between 32bit and 64bit?
> I had a 64 bit chip 10 years ago and most of you probably did too.
Intel didn't put out an x86-64 chip until 2004, and their first desktop chip wasn't until early 2005 (IIRC). AMD's first 64-bit chip (Opteron) wasn't until 2003. Neither of these were mass market for quite a few years; it wasn't until 2006 that you really started seeing them in mass-market desktops. Now, there were exceptions of course, most notably the iMac and PowerMac G5, but 64-bit machines really weren't in the hands of general users until 2006-2007.
Intel didn't put out an x86-64 chip until 2004, and their first desktop chip wasn't until early 2005 (IIRC). AMD's first 64-bit chip (Opteron) wasn't until 2003. Neither of these were mass market for quite a few years; it wasn't until 2006 that you really started seeing them in mass-market desktops. Now, there were exceptions of course, most notably the iMac and PowerMac G5, but 64-bit machines really weren't in the hands of general users until 2006-2007.
Athlon64, released in 2003, was quite popular. In the middle of the 2004 most of the AMD desktop processors (athlon, sempron) were 64-bit. So it wasn't "quite a few years" exactly. Only netbooks brought 32bit back to life somehow.
Now that I think about it, rplnt is right it was late 2003 I got an athlon64, so 9 years.
While having a 64-bit OS is useful, the majority of apps I work on never use anywhere near 4GB. Firefox has distributed 64-bit builds, so it is not the case that they aren't willing to put the work in. However, there turns out to be basically no advantage to running a 64-bit web browser.
If you're a heavy browser user, or if you simply never close your browser, you'll frequently run into the scenario where 32 bit Firefox reaches the 2GB virtual memory limit, whereupon it gets killed. Yep, it's 2GB, atleast on 32bit OS (I'm on Win 7 32bit).
Just the convenience factor of not having to restart my browser frequently is enough to make me want to embrace x64. My blocker is that my corporate IT policy is to have 32 bit OS.
Just the convenience factor of not having to restart my browser frequently is enough to make me want to embrace x64. My blocker is that my corporate IT policy is to have 32 bit OS.
And here I was thinking they must be already working on the 64 bit for ARMv8 and Android for a 2014 release.
This is talking specially about 64-bit on windows, related to windows-specific problems. Linux and osx have fully-functioning 64-bit versions, so this won't hinder ARM 64-bit.