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
We do have nightly x86-64 builds:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/
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.
--BDS
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.
-David
--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/
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?
--BDS
> 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.
-Ted
> 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.
zw
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.
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).
Peter.
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.
Peter.
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.
Brian Polidoro
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.
zw
> 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.
-Ted
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.
jjb
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.
zw
> "John J. Barton" <johnj...@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.
-Rob
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.
Robert Kaiser
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
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.
zw
It is also a parity issue too. JavaScriptCore and now v8 have native
x86_64 bit support.
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...
> 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?
zw
I *really* doubt that this has anything to do with x64.
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
-Ted
Nobody told me but I noticed some time ago.
Actually I'm really waiting for a x86-64 port of tracemonkey. Now that
even the Java plugin is "usable" as 64bit version there is no reason
anymore to provide an easy workaround to make it possible for
distribution users to switch to the 32bit build.
I'm not sure if I would urge Mozilla to provide official x86_64 builds
as I don't really care. I only want Mozilla to fix issues if encountered
(when I can't fix them myself) and apparently that worked quite well for
the last five years. (excluding tracemonkey :-()
Wolfgang
We knew as well, and were reminded again recently, since using the JIT
will cause the build to exit at startup on systems with SELinux
enforcing execmem, such is the intended goal for the next release of
Fedora. (Note that we've temporarily reverted the SELinux change and
one of our engineers, Martin Stransky, is working on this bug).
Rob