However, we do not make x86-64 releases, for several reasons:
* many of the most popular plugins are only available on x86 * we don't do active QA on the x86-64 builds * because the i686 builds work fine on almost every x86-64 Linux distro. * Optimizations such as the tracemonkey JIT engine have yet not been implemented for x86-64, which means that the i686 build will be faster than the x86-64 build.
In most cases end-users receive Mozilla/Firefox from their Linux distros in any case, and the distro will decide whether to use i686 (for plugin/extension compatibility) or to use x86-64.
On Wednesday 2009-08-19 09:41 -0400, Benjamin Smedberg wrote:
> However, we do not make x86-64 releases, for several reasons:
> * many of the most popular plugins are only available on x86
Which? Flash and Java are available.
> * we don't do active QA on the x86-64 builds > * because the i686 builds work fine on almost every x86-64 Linux distro. > * Optimizations such as the tracemonkey JIT engine have yet not been > implemented for x86-64, which means that the i686 build will be faster than > the x86-64 build.
I thought the answer was more "we hadn't gotten around to it" than than "we didn't think it was a good idea". I think we should get around to it, though. Anecdotally, I think it's what a significant portion of Linux users are running. I'd be interested to see real data on that, though.
> On Wednesday 2009-08-19 09:41 -0400, Benjamin Smedberg wrote: >> However, we do not make x86-64 releases, for several reasons:
>> * many of the most popular plugins are only available on x86
> Which? Flash and Java are available.
I didn't know Flash was available on x86-64... I guess that nullifies that argument.
> I thought the answer was more "we hadn't gotten around to it" than
Doing a release without tracemonkey seems silly if the i686 builds work (I kinda presume they would end up being faster than the x86-64 builds). I think Linux x86-64 is only marginally valuable compared to the release engineering and QA work that would be required to actually make it a released product.
Besides allowing for greater memory usage and producing somewhat better code because of more registers, are there significant other reasons why an x86-64 build would be better than an i686 build for Linux users who are running 64-bit distros?
On Wed, Aug 19, 2009 at 12:46 PM, Benjamin Smedberg <benja...@smedbergs.us>wrote:
> Besides allowing for greater memory usage and producing somewhat better > code > because of more registers, are there significant other reasons why an > x86-64 > build would be better than an i686 build for Linux users who are running > 64-bit distros?
I think dbaron's point is that Linux distributions are shipping x86-64 builds to their users whether we care or not. There are likely to be a fair amount of users on a 64-bit Linux these days, since things like nspluginwrapper have been around for a long time (making the plugin issue not a big deal), therefore we stand to gain by supporting this configuration and making those users' lives better. I run a 64-bit Ubuntu here, and I often use the distro-supplied Firefox just because it's convenient.
That's not to say that officially supporting these builds is simple, since we don't currently run unit tests, leak tests, or Talos tests on them, plus we would need extra build and talos slaves setup to run tests on them, since all our existing slaves are 32-bit.
Benjamin Smedberg <benja...@smedbergs.us> wrote: > I didn't know Flash was available on x86-64... I guess that nullifies > that argument.
It's available but it's horribly buggy, crashes the browser on a daily basis for me. :-(
> Besides allowing for greater memory usage and producing somewhat > better code because of more registers, are there significant other > reasons why an x86-64 build would be better than an i686 build for > Linux users who are running 64-bit distros?
All the x86-64 distros I am familiar with treat 32-bit binaries as second-class, legacy only, to the point where it's a crapshoot whether all the system libraries required to run the official i686 build are available in a 32-bit version at any given time.
I use hand-built 64-bit mozilla-central and the distro's 64-bit 3.0 (they haven't gotten around to picking up 3.5 yet) just because of this. Yeah, it means I don't get Tracemonkey. *shrug*
http://popcon.debian.org/stat/submission.png is a graph of Debian users as a function of CPU architecture. The top two lines (dark red and dark green) are 32- and 64-bit x86 installs; it's on a log scale, so what that says to me is there are approximately half as many users running x86-64 as x86-32, and the proportion is rising. I think it's pretty safe to generalize from this sample to all Linux users, so I *do* think the engineering and QA effort to make x86-64 Linux a first tier platform will be worthwhile - if not now, then within the year.
On Wednesday 2009-08-19 12:46 -0400, Benjamin Smedberg wrote:
> Besides allowing for greater memory usage and producing somewhat better code > because of more registers, are there significant other reasons why an x86-64 > build would be better than an i686 build for Linux users who are running > 64-bit distros?
Because they don't want to ship the dozens of libraries that we would depend on in their x86 form? (In order to install x86 Firefox on x86_64 Ubuntu, you need to install the ia32-libs package from universe (i.e., unsupported).)
And Linux isn't the only platform moving towards x86_64; it sounds like Mac is as well. We'll want tracemonkey on x86_64 at some point. (And I thought there were patches that had it nearly-working at one point...)
Prior to tracemonkey, Firefox x86_64 was faster than Firefox x86 (comparing our nightlies against each other). Maybe, given tracemonkey's availability, some distros might switch.
> * Optimizations such as the tracemonkey JIT engine have yet not been > implemented for x86-64, which means that the i686 build will be faster than > the x86-64 build.
I don't think I have seen this statement anywhere yet, at least not with the same clarity as in this thread. Has anybody told the distro maintainers that they are not running JIT if they build 64bit? How can a user see this (except noticing slower speeds as e.g. the comment from "CarlosM" on https://wiki.mozilla.org/Firefox/Namoroka/Initial_Plan).
> Benjamin Smedberg <benja...@smedbergs.us> wrote:
>> I didn't know Flash was available on x86-64... I guess that nullifies >> that argument.
> It's available but it's horribly buggy, crashes the browser on a > daily basis for me. :-(
Just like 32bit Flash then. ;-) (But it hasn't crashed here in weeks, using adobe-flash-10.0.32.18.)
>> Besides allowing for greater memory usage and producing somewhat >> better code because of more registers, are there significant other >> reasons why an x86-64 build would be better than an i686 build for >> Linux users who are running 64-bit distros?
> All the x86-64 distros I am familiar with treat 32-bit binaries as > second-class, legacy only, to the point where it's a crapshoot whether > all the system libraries required to run the official i686 build are > available in a 32-bit version at any given time.
> I use hand-built 64-bit mozilla-central and the distro's 64-bit 3.0 > (they haven't gotten around to picking up 3.5 yet) just because of this. > Yeah, it means I don't get Tracemonkey. *shrug*
Is there actually a bug about JIT on 64bit? I only found bug 502373 which is specific for sparc.
> http://popcon.debian.org/stat/submission.png is a graph of Debian > users as a function of CPU architecture. The top two lines (dark red > and dark green) are 32- and 64-bit x86 installs; it's on a log scale, > so what that says to me is there are approximately half as many users > running x86-64 as x86-32, and the proportion is rising. I think it's > pretty safe to generalize from this sample to all Linux users, so I > *do* think the engineering and QA effort to make x86-64 Linux a first > tier platform will be worthwhile - if not now, then within the year.
Hmm, your Debian graph has a log y-axis, so it's hard to read off. Ubuntu has a similar graph on http://popcon.ubuntu.com/ and they give the actual current numbers below the plot. There amd64 is about 1/5th of the i386 number. For the stats tracked by Fedora (http://smolt.fedoraproject.org/static/stats/stats.html) it seems that about 1/3 of their users is on 64bit. From what I see in the Gentoo community I guess it's even more there, but I didn't find any numbers.
> I'm wondering why there's no linux x86_64 builds available? Is this > platform not supported, or is it tested with standard x86 builds?
> I couldn't find any reference, but if it was discussed already I'd be > more than happy to read the whole thread.
> thanks!
> Jacek
I saw 64-bit Mac mentioned in the thread too. But don't leave Windows behind. A couple of co-workers were saying that they were looking to buy laptops at Dell.com. And they were surprised that the default was 64-bit Windows Vista. They had to browse around through the models to find 32-bit Vista because some models they viewed only had a 64-bit Vista option. So people that don't realize the difference are going to end up buy 64-bit Windows Vista and soon Windows 7.
> > I use hand-built 64-bit mozilla-central and the distro's 64-bit 3.0 > > (they haven't gotten around to picking up 3.5 yet) just because of > > this. Yeah, it means I don't get Tracemonkey. *shrug*
> Is there actually a bug about JIT on 64bit? I only found bug 502373 > which is specific for sparc.
Bug 489146. I'm not sure why it's marked Linux specific though since the bug trail sounds like it's about having an amd64 back end at all.
> Hmm, your Debian graph has a log y-axis, so it's hard to read off. > Ubuntu has a similar graph on http://popcon.ubuntu.com/ and they give > the actual current numbers below the plot. There amd64 is about 1/5th > of the i386 number. For the stats tracked by Fedora > (http://smolt.fedoraproject.org/static/stats/stats.html) it seems that > about 1/3 of their users is on 64bit. From what I see in the Gentoo > community I guess it's even more there, but I didn't find any numbers.
I did misread the graph; there are numbers on http://popcon.debian.org/ which work out to 75% i386, 22% amd64, 3% other. It now occurs to me that Debian (as opposed to Ubuntu) might get used on more server machines, which would skew things a bit.
On Thu, Aug 20, 2009 at 10:33 AM, Brian Polidoro <polid...@yahoo.com> wrote: > I saw 64-bit Mac mentioned in the thread too. But don't leave Windows > behind. A couple of co-workers were saying that they were looking to buy > laptops at Dell.com. And they were surprised that the default was 64-bit > Windows Vista. They had to browse around through the models to find 32-bit > Vista because some models they viewed only had a 64-bit Vista option. So > people that don't realize the difference are going to end up buy 64-bit > Windows Vista and soon Windows 7.
Our 32 bit builds of Firefox work just fine on Windows x64 editions, AFAIK. Note that this is a different proposal than supporting Linux x86-64, since the Linux builds already work, it's just a matter of supporting them fully with unit/performance tests, as well as official builds. 64-bit Windows and Mac still require some porting work.
> On Wednesday 2009-08-19 09:41 -0400, Benjamin Smedberg wrote:
> > However, we do not make x86-64 releases, for several reasons:
> > * many of the most popular plugins are only available on x86
> Which? Flash and Java are available.
> > * we don't do active QA on the x86-64 builds > > * because the i686 builds work fine on almost every x86-64 Linux distro. > > * Optimizations such as the tracemonkey JIT engine have yet not been > > implemented for x86-64, which means that the i686 build will be faster than > > the x86-64 build.
> I thought the answer was more "we hadn't gotten around to it" than > than "we didn't think it was a good idea". I think we should get > around to it, though. Anecdotally, I think it's what a significant > portion of Linux users are running. I'd be interested to see real > data on that, though.
I may not be representative of anything, but I finally migrated to Linux when I got my first Opteron 64 processor. Windows did not have drivers for my hardware, but Suse Linux did. I've spent a lot of time and effort tracking down everything necessary to build 64 bit systems, with everything possible running 64 bit native code. Yes, I want 64 bit, because 64 bit is the future. Why run yesterday's code on tomorrow's hardware? AFAIK, no one is even selling 32 bit computers anymore. Go ahead and support 32 bit for another year or five, but hey, it's time to look ahead!! Put the real work into the 64 bit stuff that people will be demanding soon!! Publish the benchmarks - a significant number of people will adopt whatever is fastest, so long as it doesn't crash all the time.
> I may not be representative of anything, but I finally migrated to > Linux when I got my first Opteron 64 processor. Windows did not have > drivers for my hardware, but Suse Linux did. I've spent a lot of time > and effort tracking down everything necessary to build 64 bit systems, > with everything possible running 64 bit native code. Yes, I want 64 > bit, because 64 bit is the future. Why run yesterday's code on > tomorrow's hardware? AFAIK, no one is even selling 32 bit computers > anymore. Go ahead and support 32 bit for another year or five, but > hey, it's time to look ahead!! Put the real work into the 64 bit > stuff that people will be demanding soon!! Publish the benchmarks - a > significant number of people will adopt whatever is fastest, so long > as it doesn't crash all the time.
All other things being equal, aren't 64 bit machines half as fast as 32 bit machines, at least until you get above 4GB of memory and start paging? Every word is now twice as large as it needs to be.
"John J. Barton" <johnjbar...@johnjbarton.com> wrote:
> All other things being equal, aren't 64 bit machines half as fast as > 32 bit machines, at least until you get above 4GB of memory and start > paging? Every word is now twice as large as it needs to be.
Well, it's only every pointer; 'int' is still 32 bits. But what you say is more or less true of most 64-bit extensions to 32-bit RISC CPUs; people tend to build their PowerPC or SPARC systems with a mostly 32-bit userland but use 64-bit mode for their giant database.
x86-64 is different, mainly (it is said; I haven't analysed it myself) because the 64-bit mode brings eight more registers to the table and disables a bunch of ancient junk in the memory interface, as well as doubling the pointer size; also perhaps because both Intel and AMD are concentrating on speed in 64-bit mode rather than 32-bit mode, now. People report order of 15% *speedup* just from rebuilding in 64-bit mode, all else equal.
> "John J. Barton" <johnjbar...@johnjbarton.com> wrote:
> > All other things being equal, aren't 64 bit machines half as fast as > > 32 bit machines, at least until you get above 4GB of memory and start > > paging? Every word is now twice as large as it needs to be.
> Well, it's only every pointer; 'int' is still 32 bits. But what you > say is more or less true of most 64-bit extensions to 32-bit RISC CPUs; > people tend to build their PowerPC or SPARC systems with a mostly > 32-bit userland but use 64-bit mode for their giant database.
> x86-64 is different, mainly (it is said; I haven't analysed it myself) > because the 64-bit mode brings eight more registers to the table and > disables a bunch of ancient junk in the memory interface, as well as > doubling the pointer size; also perhaps because both Intel and AMD are > concentrating on speed in 64-bit mode rather than 32-bit mode, now. > People report order of 15% *speedup* just from rebuilding in 64-bit > mode, all else equal.
The additional registers help tremendously.
Additionally, some operations (like 64 bit math ops) aren't any slower on registers because the 32 bit variants have to clear the upper 32 bit of the corresponding 64 bit register anyways. The calling convention is different as well: x86 uses the stack to pass arguments, but x86-64 uses registers for the first 6 (4 on Windows) arguments. This gives you less memory traffic in most cases. Base pointers are (I believe) optional for Linux's ABI. Segments are gone (lose one register to TLS).
Once you move into kernel land, there are more advancements (ex: the pagetable/entry structure is different).
It's hard to say in general whether or not a given application will see a speedup for 64 bits or not. Also of note is that having a multiprocess architecture diminishes the need to move to x86-64 due to address space pressure.
Zack Weinberg wrote: > as well as > doubling the pointer size
True, that's why a lot of the 64bit binaries take significantly more memory for the same task and run slower than 32bit code due to those increased sizes. There is a trade-off in the jump between the binaries, and it rightfully is, or else we would have built 128bit processors in the 1990s.
Runaway1956 wrote: > Yes, I want 64 > bit, because 64 bit is the future. Why run yesterday's code on > tomorrow's hardware? AFAIK, no one is even selling 32 bit computers > anymore. Go ahead and support 32 bit for another year or five, but > hey, it's time to look ahead!!
Those statements clearly tell that you have no clue of what's happening under the hood and are just following some marketing talk or misguided own thought. I don't know much about details like registers and memory layout, but I grasped enough to realize that 1) practically every 64bit OS can run 32bit binaries wihtout major problems (the largest question is usually what libraries are already mapped into memory in both versions) and 2) increased sizes of pointers/addresses and instructions (what 64bit seems to actually mean) can be both a blessing and a course. On one side, things get faster if you have some additional instructions, registers and such things and can address more memory directly, on the other, some things take up double the size in memory and therefore make things slower. All in all, you need to make a trade-off. In the 1990s, it wasn't technically impossible to crerate 64bit or 128bit computers, but the trade-off made them much worse than 8/16/32bit processing, and so those routes were taken. Now there are technical reasons that 64bit can be done reasonably and so the hardware is being designed to support it, even if the software isn't really needing it in every place, it just would be too expensive (and problematic for other mostly business reasons) to develop two architectures for the desktop market at the same time. The need for 64bit computing isn't there for all systems, but it gives advantages on the hardware side in most cases, and on the OS side in a good number of cases already. On the application side, it's not that clear with what we're doing today. Things will eventually shift further, but there is not much of pressure unless for marketing reasons right now.
Robert Kaiser <ka...@kairo.at> wrote: > Zack Weinberg wrote: > > as well as > > doubling the pointer size
> True, that's why a lot of the 64bit binaries take significantly more > memory for the same task and run slower than 32bit code due to those > increased sizes. > There is a trade-off in the jump between the binaries, and it > rightfully is, or else we would have built 128bit processors in the > 1990s.
Uh, did you read my entire message? The point was that x86-64 is different from other 64-bit processors and so *even though* the pointer size doubles, switching tends to be a win.
On Aug 19, 12:23 pm, "L. David Baron" <dba...@dbaron.org> wrote:
> On Wednesday 2009-08-19 12:46 -0400, Benjamin Smedberg wrote:
> > Besides allowing for greater memory usage and producing somewhat better code > > because of more registers, are there significant other reasons why an x86-64 > > build would be better than an i686 build for Linux users who are running > > 64-bit distros?
> And Linux isn't the only platform moving towards x86_64; it sounds > like Mac is as well. We'll want tracemonkey on x86_64 at some > point. (And I thought there were patches that had it nearly-working > at one point...)
It is also a parity issue too. JavaScriptCore and now v8 have native x86_64 bit support.
On Aug 20, 10:54 am, Ted Mielczarek <ted.mielcza...@gmail.com> wrote:
> Our 32 bit builds of Firefox work just fine on Windows x64 editions, AFAIK. > Note that this is a different proposal than supporting Linux x86-64, since > the Linux builds already work, it's just a matter of supporting them fully > with unit/performance tests, as well as official builds. 64-bit Windows and > Mac still require some porting work.
> -Ted
Not quite true. On x86-64 Windows Vista Home Premium, Firefox (x86-32) crashes whenever JS intensive pages are closed (e.g. Gmail, etc.)
Plus, most, if not all, computers sold today are now 64-bit capable (this is excluding netbooks). Macs have been 64-bit capable for some time now, and Snow Leopard switches to 64-bit internal OS code. Linux distros have been 64-bit capable for quite some time, even before Windows and Mac OS X. Demands for 64-bit builds are simply going to rise...
King InuYasha <ngomp...@gmail.com> wrote: > On Aug 20, 10:54 am, Ted Mielczarek <ted.mielcza...@gmail.com> wrote:
> > Our 32 bit builds of Firefox work just fine on Windows x64 > > editions, AFAIK. Note that this is a different proposal than > > supporting Linux x86-64, since the Linux builds already work, it's > > just a matter of supporting them fully with unit/performance tests, > > as well as official builds. 64-bit Windows and Mac still require > > some porting work.
> > -Ted
> Not quite true. On x86-64 Windows Vista Home Premium, Firefox (x86-32) > crashes whenever JS intensive pages are closed (e.g. Gmail, etc.)
Do you know this to be a 32bit-on-64bit issue specifically, though?
> On Aug 20, 10:54 am, Ted Mielczarek<ted.mielcza...@gmail.com> wrote:
>> Our 32 bit builds of Firefox work just fine on Windows x64 editions, AFAIK. >> Note that this is a different proposal than supporting Linux x86-64, since >> the Linux builds already work, it's just a matter of supporting them fully >> with unit/performance tests, as well as official builds. 64-bit Windows and >> Mac still require some porting work.
>> -Ted
> Not quite true. On x86-64 Windows Vista Home Premium, Firefox (x86-32) > crashes whenever JS intensive pages are closed (e.g. Gmail, etc.)
I *really* doubt that this has anything to do with x64.
jfelps <jfe...@gmail.com> wrote: > It is also a parity issue too. JavaScriptCore and now v8 have native > x86_64 bit support.
Do note that for all this talk, 64-bit JITting is on its way (Graydon just moved us that much closer with the latest nanojit merge) and only needs a few more changes on our end to start working. -- Blake Kaplan
