64-bit Windows Nightlies

[Ed Morley]

64-bit MSVC Windows builds are only tier 2 [1], but yet over half of our Windows Nightly users are using them [2], meaning that they are:

* Not testing the actual bits shipped to aurora, beta or release channel Windows users [3], thereby reducing their use to us. In some cases they are unable to test entire features, for example the Mozilla Maintenance Service [4].

* Subject to significant performance regressions compared to 32-bit builds - which would have resulted in backouts had they occurred on any other platform. In the last 3 weeks alone, V8 regressed by 80% [5] and SunSpider by 20% [6].


Additional problems:

* Mozilla-central is the only tree that runs tests on Win64 - which with the increased usage of mozilla-inbound, means that regression ranges can be as large as a 100 changeset merge [7] and so are time-consuming to investigate (i.e.: often aren't).

* Win64 tests are hidden by default on TBPL (since it is not reasonable to back out an entire merge just because it originated from a tree that doesn't run those tests), so both intermittent and permanent oranges are being ignored.

* Amazingly, there is still the perception by some Windows Nightly users that the 64-bit MSVC builds are faster than their 32-bit counterparts [8], whereas even before the recent regressions that was not the case [5] [6].

* Users of 64-bit versions of Windows may be under the impression that 64-bit builds of Nightly are somehow "more correct" for their platform, especially since http://nightly.mozilla.org displays 32-bit and 64-bit Windows Nightly builds with equal prominence and no indication that the 64-bit builds are experimental/effectively untested.

* Whilst there was a thorough discussion of the Win64 pros/cons [9], a follow-up summary of facts [10], and internally most of us know that Win64 builds aren't something that we'll be focusing on near-term - there doesn't appear to have been any public newsgroup/blog postings communicating the final decision. So it's not surprising that the average Nightly user is not aware that Win64 builds are pretty much unsuited for public consumption.

--

As a result, I am concerned that we're not only shooting ourselves in the foot with respects to 32-bit Nightly testing coverage, but also doing over half of our Windows Nightly users a disservice by shipping effectively untested and likely slower builds - without many of them even being aware of it.

Ok, so what now?

Option A:

* Alter http://nightly.mozilla.org such that 64-bit Windows builds are clearly marked as experimental & link to newsgroup/blog posts with an explanation.
* Make the Win64 decision more widely visible using newsgroups and a Planet blog post (though I imagine this thread will cover the former).
* Consider reaching out to the current Win64 Nightly users using a custom 'What's New' page advising that they are using a tier 2 build and the implications of that.
* Either dedicate the resources so that we can run Win64 tests on all trees (and eventually unhide them), or else switch off Win64 tests on mozilla-central for now, since they are currently hidden and taking up slaves for little benefit.

Option B: (my personal preference)

* Switch off Nightly Win64 builds (at least for the short to medium term).
* Still do per-push tinderbox Win64 builds to make sure we don't break anything major, but switch off the all tests (if we're not going to run them on all trees).
* Remove the Win64 links on http://nightly.mozilla.org.
* Transition Win64 Nightly users to 32-bit Nightly builds, with an unprompted update and an appropriate 'What's New' page.

Any other ideas/thoughts?

Thank you for reading! :-)


Ed


[1] https://developer.mozilla.org/en/Supported_build_configurations

[2] 33,507 WINNT_x86-msvc vs. 37,460 WINNT_x86_64-msvc mean daily active installations of Firefox 13.0a1 over the last two weeks.

[3] Aurora, beta and release channel Windows builds (both per push and nightlies) are 32-bit only.

[4] The Mozilla Maintenance Service is currently only enabled for x86 builds, pending bug 715876.

[5] V8 MSVC 32bit vs 64bit:
http://graphs-new.mozilla.org/graph.html#tests=[[76,1,19],[76,1,12]]&sel=1328150633518.812,1330185701601.2605&displayrange=90&datatype=running

[6] SunSpider MSVC 32bit vs 64bit:
http://graphs-new.mozilla.org/graph.html#tests=[[75,1,19],[75,1,12]]&sel=1328278981105.6865,1330209574209.1348&displayrange=90&datatype=running

[7] Feb 17th Dromaeo regressions (V8 by 81.1%, CSS by 31.8%, String/Array/Eval/Regex by 20.6%, SunSpider by 10.8%), with an initial 102 changeset regression range:
https://groups.google.com/d/msg/mozilla.dev.tree-management/5VxnjZSzZOw/b7u69Rv0qsEJ

[8] http://www.reddit.com/r/firefox/comments/puaw3/firefox_nightly_is_blazing_fast/ + many examples within: http://forums.mozillazine.org/viewtopic.php?f=23&t=2239223

[9] https://groups.google.com/d/topic/mozilla.dev.planning/Mrba6hvl5-w/discussion

[10] https://groups.google.com/d/topic/mozilla.dev.planning/aeTXSZ_WFAs/discussion

[Asa Dotzler]

On 2/27/2012 5:58 PM, Ed Morley wrote:

> Option B: (my personal preference)
>
> * Switch off Nightly Win64 builds (at least for the short to medium
> term). * Still do per-push tinderbox Win64 builds to make sure we
> don't break anything major, but switch off the all tests (if we're
> not going to run them on all trees). * Remove the Win64 links on
> http://nightly.mozilla.org. * Transition Win64 Nightly users to
> 32-bit Nightly builds, with an unprompted update and an appropriate
> 'What's New' page.

From the Product standpoing, I recommend with this option. We will not
be shipping official Win64 builds any time soon (if ever) and so
dividing our testing is only cost with no reward.

- A

[Asa Dotzler]

That didn't come out well :) From the Product *standpoint* I recommend
*going* with this option.

-A

[KWierso]

> * Amazingly, there is still the perception by some Windows Nightly users that the 64-bit MSVC builds are faster than their 32-bit counterparts [8], whereas even before the recent regressions that was not the case [5] [6].

Could it be the case that the perceived performance increase is from not having as many worthless/leaking/performance-destroying addons/plugins available for 64-bit builds to be damaged by? (If all the junk out there only targets 32-bit Firefox, x64 builds would seem better.)

[Anthony Hughes]

I don't believe we (QA) have done any real amount of testing using the Win64 Nightlies (unless a situation arose that specifically called for it). So in terms of QA, proceeding down either path is no net loss, no net gain.

_______________________________________________
dev-planning mailing list
dev-pl...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-planning

[Brian R. Bondy]

On Feb 27, 9:11 pm, Asa Dotzler <a...@mozilla.org> wrote:
> > ...Option B...
>  From the Product standpoint, I recommend with this option. We will not

> be shipping official Win64 builds any time soon (if ever) and so
> dividing our testing is only cost with no reward.

I support option B up until we decide to put resources towards making
64-bit MSVC Windows builds tier 1.
In addition to giving us extra early testing, there are also several
bugs (such Bug 715876, bug 727873, bug 711210) which can suck precious
development time that could be better spent elsewhere.

[Christopher Blizzard]

On 2/27/2012 6:11 PM, Asa Dotzler wrote:

Is this a change? I thought we were looking to move because major
plugins were largely available as 64 bit?

--Chris

[Asa Dotzler]

I did conduct a fact gathering exercise to try to better understand the
pros and cons. Right now, I don't believe it's worth making 64-bit
builds official. I've been meaning to come back to this group with my
recommendation in more detail. I'll try to get to that ASAP.

- A

[Dao]

I don't think these builds should be available on
http://nightly.mozilla.org/ at all, regardless of whether they're built.

[sag net]

On Feb 28, 2:58 am, Ed Morley <bmo.takethis...@edmorley.co.uk> wrote:
> Option B: (my personal preference)
>

> * Transition Win64 Nightly users to 32-bit Nightly builds, with an unprompted update and an appropriate 'What's New' page.

Back to 32-bit Nightly?, never! In this case i have only one option,
switching to Opera 12 64bit dev build.
The 64-bit build is for me the last reason using Firefox, why i should
switch to 32-bit Firefox, if i wanted fast 32-bit browser, i would use
Chrome.

[Benjamin Smedberg]

What exactly makes you think that the 64-bit build is better than the
32-bit build? We have initial data which shows that it in general the
64-bit build uses more memory and doesn't run much faster. This isn't
always true on certain testcases where SSE instructions can improve
things, but for the vast majority of browsing tasks there is no difference.

Do you have data which indicates otherwise?

--BDS

[sag net]

On Feb 28, 3:33 pm, Benjamin Smedberg <benja...@smedbergs.us> wrote:
> What exactly makes you think that the 64-bit build is better than the
> 32-bit build? We have initial data which shows that it in general the
> 64-bit build uses more memory and doesn't run much faster. This isn't
> always true on certain testcases where SSE instructions can improve
> things, but for the vast majority of browsing tasks there is no difference.
>
> Do you have data which indicates otherwise?
>
> --BDS

First, because is a Native program and secondly i think it has better
security.
I don't care if the 64-bit build use more memory, currently i have 8GB
memory on my PC and in near future i will upgrade to 16GB.

[Wayne Mery]

For me 64bit on win7 has been more stable with lots of tabs.
(using nightly since ~October 1)
Yes, it does use more memory - doesn't matter to me.

--
contribute ... http://wiki.mozilla.org/Thunderbird:Testing

[Christopher Blizzard]

On 2/28/2012 10:07 AM, Wayne Mery wrote:
> For me 64bit on win7 has been more stable with lots of tabs.
> (using nightly since ~October 1)
> Yes, it does use more memory - doesn't matter to me.
>

Do we have crash data that shows that it crashes less/more? (I'd guess
less because we're less likely to run out of memory!)

--Chris

[lordkit...@gmail.com]

I would rather you guys actually put more work into it, users have clearly been asking for a 64bit for a long time and when the nightly came out the users who wanted 64bit used it.

I am aware that 64bit is slightly slower (peacekeeper puts the 64bit build juuuuust behind the 32) but it in my experience has been much more stable when working with lots of tabs or sites with a large amount of content.

At the very least please dont remove the 64bit build or ill be forced to use something like waterfox or one of the many other 64bit variants floating around, and i would rather not since they seem to have issues.

The argument against 64 used to be plugin support but so far it seems a vast array of plugins support the 64bit build so that argument no longer flies.
It is possible to squeeze performance out of 64bit for a few select tasks (but it boils down to is the %ofincrease = or > time to make happen) but other advantages are there mainly memory being able to go as high as it damn well pleases.

Almost every computer being sold now (exept the lower end budget oc/laptops) are being shipped with 4or more GB of ram and a 64bit OS so i think its more then worth putting more time into the 64bit build and wish you would reconsider, as i would hate for you too loose users over this and i can promise you that you would.

[Dave Mandelin]

On Feb 28, 2:34 am, Dao <d...@design-noir.de> wrote:
> I don't think these builds should be available onhttp://nightly.mozilla.org/at all, regardless of whether they're built.

I agree with that.

My personal inclination is to keep supplying 64-bit builds somehow,
because it seems like a lot of enthusiastic users (including a power-
user friend of mine) really like having them. But we consider it an
experimental thing, so it shouldn't be out there in a place that
suggests it is a fully supported product.

I definitely do not like the idea of switching over users from 64-bit
to 32-bit Nightly builds without at least asking nicely and saying why
we would like people to do that (and why we think they would like to
do it).

Dave

[Ben Hearsum]

On 02/27/12 08:58 PM, Ed Morley wrote:
> Option B: (my personal preference)
>
> * Switch off Nightly Win64 builds (at least for the short to medium term).
> * Still do per-push tinderbox Win64 builds to make sure we don't break anything major, but switch off the all tests (if we're not going to run them on all trees).

From a RelEng standpoint there's almost no difference between this and
the current state of things. If we have _any_ builds at all happening
regularly, we have to maintain a pool of machines to support them.
Obviously that's not the only factor here, but for us, it really sucks
to have to maintain a platform that almost nobody else cares about.

[Asa Dotzler]

A lot of this was covered in earlier threads on this topic. See
"Firefox 64-bit for Windows: data gathering" and "Firefox 64-bit for
Windows: what we know"

I don't think we have crash data that can demonstrate this and I've been
told it's not necessarily a win.

> • With a larger virtual address space, people using a 64-bit Firefox
> on 64-bit Windows could see fewer out of memory crashes (actually,
> out-of-virtual-address-space crashes.)
>
> •• This is not necessarily a clear win because 64-bit builds will use
> more memory overall and we do not have a clear picture of Firefox's
> address space usage in the wild.

- A

[Boris Zbarsky]

On 2/28/12 10:41 AM, sag net wrote:
> First, because is a Native program

What does that mean, exactly?

> and secondly i think it has better security.

It doesn't.

The strongest argument for 64-bit builds continues to be their better
handling of situations where we end up using >2GB of address space...

-Boris

[James May]

On 29 February 2012 08:42, Boris Zbarsky <bzba...@mit.edu> wrote:

> On 2/28/12 10:41 AM, sag net wrote:
>
>> First, because is a Native program
>>
>
> What does that mean, exactly?
>
>

But... 64 is twice as many bits as 32!

Bigger numbers are better!

>
> and secondly i think it has better security.
>>
>
> It doesn't.
>

Isn't there some benefit with more room for ASLR and something about the
calling convention being better?

With the con of course that it gets less testing.

> The strongest argument for 64-bit builds continues to be their better
> handling of situations where we end up using >2GB of address space...

Do we still not have stats on how often this happens?



> -Boris


Two other points I can think of:

* x64 builds are used on many linux distros, increased testing for the
platform independent code couldn't hurt.
* testing out the SSE2 generating code in MSVC might be useful if/when we
become able to use more cpu specific binaries (ie. stub instaler?) , but
switching to a build config ala waterfox would probably be more effective
on this front.

If this were a vote, I'd go for putting up a warning firstrun and marking
the download with stronger language. I'm not familiar with how many releng
resources x64 nightlies take up though.


-- James

[Boris Zbarsky]

On 2/28/12 5:07 PM, James May wrote:
> Isn't there some benefit with more room for ASLR

Hmm... maybe.

> and something about the
> calling convention being better?

I don't think that affects security.

> * x64 builds are used on many linux distros, increased testing for the
> platform independent code couldn't hurt.

Since all our Mac OS 10.6 and 10.7 users (including all recent releases)
are on 64-bit builds, the platform-independent part is getting a
reasonable amount of testing, I suspect...

-Boris

[Ben Hearsum]

On 02/28/12 05:07 PM, James May wrote:
> If this were a vote, I'd go for putting up a warning firstrun and marking
> the download with stronger language. I'm not familiar with how many releng
> resources x64 nightlies take up though.

Doing nightlies only takes up marginally more resources if we're already
doing on-change builds. However, on-change builds take up a bunch of
resources already, which is pretty undesirable for a platform we're not
shipping IMO.

[Ben Hearsum]

On 02/28/12 05:07 PM, James May wrote:

> If this were a vote, I'd go for putting up a warning firstrun and marking
> the download with stronger language. I'm not familiar with how many releng
> resources x64 nightlies take up though.

[Justin Dolske]

On 2/27/12 5:58 PM, Ed Morley wrote:

> Option B: (my personal preference)
>
> * Switch off Nightly Win64 builds (at least for the short to medium term).

I have 4 concerns off the top of my head:

1) If we turn off Win64 builds now, how much extra effort will be
required later to get them working and shippable? And is that extra
delay (on top of all the existing ambiguity/delay/work) worth it? And
how about versus an Option C of getting Win64 builds/tests going in
inbound/try, such that it becomes more like a tier-1 platform?

2) Conversely, if there's a proposal to simply never ship Win64 in the
foreseeable future, that should be raised and decided before we spend a
lot of time in this thread. :) My understanding of the status quo is
that we're eventually going to ship it, but it's not a high priority or
on a specific schedule.

3) Competitive landscape. I would be be worried about further eroding
market/mindshare if competitive browsers are shipping 64-bit builds or
have a plan for doing so. [IE has a 64-bit version but defaults to 32,
what's the state of Chrome's and Opera's plans?] If people are under the
mistaken impression that the 64-bit builds are blazing fast, I'd really
love to use that little thread to help start unraveling the whole
"chrome is king" sweater (by fixing our 64 bit issues), and not just say
"wrong! those builds are terrible and slow!".

4) 64-bit everywhere? How long until the majority of our userbase is
64-bit capable, and supporting 32-bit code become a legacy headache?
Probably still a ways out, but the future seems clear enough to me --
eventually most platforms will be 64-bit. Linux seems to already be
there (distros are commonly shipping the 64-bit version, no?), and OS X
is almost there (istr an earlier thread about going 64-bit only once
10.5 support is dropped). I would assume the fraction of Windows users
with 64-bit capable systems is only going to grow. Not sure what the
outlook is for mobile.

I guess there's one other meta-issue that comes to mind... We generally
know that our Nightly population is quite often just not representative
of our general population (Farmville, anyone?). I don't want to ship
crap to our users, but it's also not clear to me that we would get a lot
of incremental value from moving some or all of them to 32bit builds.

Justin

[Justin Lebar]

> Not sure what the outlook is for mobile.

Mobile will be 32-bit for the next two or three years, at least.
ARMv8 is the first 64-bit architecture from ARM, and it exists only on
paper at the moment. It's not even clear to me whether ARMv8 is
targeting phones, or just servers. We'd need to wait until we no
longer support ARMv7 until we could drop 32-bit ARM.

(FWIW, I'm in favor of more 64-bit on desktop. The extra virtual
address space eliminates an entire class of crashes.)

-Justin

[sag net]

On Feb 29, 12:23 am, Justin Dolske <dol...@mozilla.com> wrote:

> 3) Competitive landscape. I would be be worried about further eroding
> market/mindshare if competitive browsers are shipping 64-bit builds or
> have a plan for doing so. [IE has a 64-bit version but defaults to 32,
> what's the state of Chrome's and Opera's plans?] If people are under the
> mistaken impression that the 64-bit builds are blazing fast, I'd really
> love to use that little thread to help start unraveling the whole
> "chrome is king" sweater (by fixing our 64 bit issues), and not just say
> "wrong! those builds are terrible and slow!".

Opera is Working on 64-bit build.
http://dev.opera.com/articles/view/64-bit-opera-and-out-of-process-plug-ins/

[Brian Smith]

Boris Zbarsky wrote:
> The strongest argument for 64-bit builds continues to be their better
> handling of situations where we end up using >2GB of address space...

We should investigate startup performance on Win8. It could be bad if WoW64 didn't get loaded at startup, forcing us to pay the cost of loading it during Firefox startup.

- Brian

[Henri Sivonen]

On Wed, Feb 29, 2012 at 1:23 AM, Justin Dolske <dol...@mozilla.com> wrote:
> 3) Competitive landscape. I would be be worried about further eroding
> market/mindshare if competitive browsers are shipping 64-bit builds or have
> a plan for doing so.

Indeed. Metro IE10 on 64-bit Windows 8 seems to be a 64-bit app. (The
desktop IE10 launches as 32-bit on 64-bit Windows 8, but it's
positioned as a backward compat mode anyway.) Opera is preparing a
64-bit version for Windows.

When those ship, Firefox and Chrome will look like they are lagging.
If Chrome ships 64-bit on Windows, too, Firefox will look like its
lagging even more badly. At that point, saying that we measured this
or that won't matter for mindshare.

(As a technical argument, running out of address space less often
would be nice.)

--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/

[Chris Peterson]

On 3/1/12 1:33 AM, Henri Sivonen wrote:
> If Chrome ships 64-bit on Windows, too, Firefox will look like its
> lagging even more badly. At that point, saying that we measured this
> or that won't matter for mindshare.

Many early adopters are leaving Firefox for Chrome. Shipping a 64-bit
Firefox before Chrome (even as a non-default install) would give these
trendsetting users a reason to choose (and evangelize) Firefox.

More than half of Windows Nightly users install 64-bit builds. Do they
really want Nightly builds or do they just want 64-bit builds? If 64-bit
Nightly builds went away, many of those users might too.


chris p.

[Asa Dotzler]

On 3/1/2012 10:02 AM, Chris Peterson wrote:
> On 3/1/12 1:33 AM, Henri Sivonen wrote:
>> If Chrome ships 64-bit on Windows, too, Firefox will look like its
>> lagging even more badly. At that point, saying that we measured this
>> or that won't matter for mindshare.
>
> Many early adopters are leaving Firefox for Chrome. Shipping a 64-bit
> Firefox before Chrome (even as a non-default install) would give these
> trendsetting users a reason to choose (and evangelize) Firefox.

I'd like to understand why you believe that. Do we have any data saying
that users want or need 64-bit Firefox?

> More than half of Windows Nightly users install 64-bit builds. Do they
> really want Nightly builds or do they just want 64-bit builds? If 64-bit
> Nightly builds went away, many of those users might too

It's not because they're seeking out 64-bit builds. It's because this
page http://nightly.mozilla.org/ puts 64-bit at the top and those with
64-bit systems think that we are recommending it for them. I'd wager
that if we took the 64-bit build off of http://nightly.mozilla.org/ that
we'd see those numbers revert to an overwhelming majority of 32-bit
downloads and users over time.

- A

[Gian-Carlo Pascutto]

On 1/03/2012 19:34, Asa Dotzler wrote:

>> Many early adopters are leaving Firefox for Chrome. Shipping a 64-bit
>> Firefox before Chrome (even as a non-default install) would give these
>> trendsetting users a reason to choose (and evangelize) Firefox.
>
> I'd like to understand why you believe that. Do we have any data saying
> that users want or need 64-bit Firefox?

Probably anecdotal data, but just like Dave Mandelin, some power-user
friends of mine like them. I know one of them uses it because he has
image discarding turned off, and can have Firefox use all his RAM to
switch quicker between tabs (which would just crash quickly on 32-bits).
So you could say he's using it as a workaround for our ImageSuck situation.

I wouldn't be surprised if other power-users came up with similar
things, nor would I be surprised if some are running it because 64 is
obviously more than 32.

>> More than half of Windows Nightly users install 64-bit builds. Do they
>> really want Nightly builds or do they just want 64-bit builds? If 64-bit
>> Nightly builds went away, many of those users might too
>
> It's not because they're seeking out 64-bit builds. It's because this
> page http://nightly.mozilla.org/ puts 64-bit at the top

The normal build is left. The 64-bit build is not on top of it. I agree
this page doesn't do a good job of telling users they don't really want
to download the 64-bit one unless they understand the disadvantages.

--
GCP

[spec...@gmx.de]

On Thursday, March 1, 2012 7:34:17 PM UTC+1, Asa Dotzler wrote:
> It's not because they're seeking out 64-bit builds. It's because this
> page http://nightly.mozilla.org/ puts 64-bit at the top and those with
> 64-bit systems think that we are recommending it for them. I'd wager
> that if we took the 64-bit build off of http://nightly.mozilla.org/ that
> we'd see those numbers revert to an overwhelming majority of 32-bit
> downloads and users over time.
>
> - A

In other words, you think the users are too stupid choose the right build?

[Jeff Walden]

On 03/01/2012 11:20 AM, spec...@gmx.de wrote:
> In other words, you think the users are too stupid choose the right build?

"Stupid" is the wrong way to put it. There's a finite amount of time in the day. There's a finite number of things any person can care about. Under those limitations, lots of people don't prioritize understanding the particular tradeoffs here to decide whether to download a 32-bit build or a 64-bit build. And that's not necessarily a bad thing -- maybe they're doing something much more "important" the rest of the time, like doing drug research on treatments for pancreatic cancer or something.

It is possible to be under-informed, even rationally under-informed, without being stupid.

Jeff

[Jeff Walden]

On 03/01/2012 10:34 AM, Asa Dotzler wrote:
> I'd like to understand why you believe that. Do we have any data saying that users want or need 64-bit Firefox?

If I had to use a 32-bit build on Windows (I'm Linux 64-bit now), I'm pretty sure I'd be in severe pain, given that I have multiple browser profiles with 150+ tabs open in them, and virtual memory use regularly exceeding 2GB. (For comparison, my Chrome profile currently contains 95 tabs and consumes 4027340K of "private" memory, per their about:memory. So we're actually doing not bad on the memory usage front, if the two cases are not wildly incomparable.)

It's an esoteric use case, to be sure, but I've talked to patent examiners who were using 64-bit Firefox 3.6 because 1) we don't ship 64-bit on Windows, 2) for the number of tabs they have open, 32-bit builds can't cope, and 3) that was the random 64-bit build they happened to stumble upon. This was a month or so after Firefox 4 shipped.

http://whereswalden.com/2011/04/25/washington-d-c-part-3-second-psot/

I don't think we can so easily brush off concerns about exhausting address space. Many users will never come close, sure. But some will do so regularly.

Jeff

[L. David Baron]

But it's not pure disadvantages for users with more than 2GB or so
of RAM. Users with 2GB or less should just use the 32-bit builds,
sure. But users with more have a tradeoff between the ability to
have more pages open without crashing vs. a wider range of plugins
and binary extensions being available. (But Flash is available on
64-bit Windows now, so for users who are able to download Flash
themselves, more plugins and binary extensions might just be a
disadvantage since it means more undesired software hooking in to
Firefox.)

-David

--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla http://www.mozilla.org/ 𝄂

[Michael Lefevre]

On 01/03/2012 19:54, Jeff Walden wrote:
> On 03/01/2012 11:20 AM, spec...@gmx.de wrote:
>> In other words, you think the users are too stupid choose the right
>> build?
>
> "Stupid" is the wrong way to put it. There's a finite amount of time in
> the day. There's a finite number of things any person can care about.
> Under those limitations, lots of people don't prioritize understanding
> the particular tradeoffs here to decide whether to download a 32-bit
> build or a 64-bit build. And that's not necessarily a bad thing -- maybe
> they're doing something much more "important" the rest of the time, like
> doing drug research on treatments for pancreatic cancer or something.

If they don't care about their browser and don't have time to prioritise
understanding it, and to file bugs and fix their installations when it
goes wrong, they probably shouldn't be running nightly builds at all.

Michael

[Jeff Walden]

On 03/01/2012 02:34 PM, Michael Lefevre wrote:
> If they don't care about their browser and don't have time to prioritise understanding it, and to file bugs and fix their installations when it goes wrong, they probably shouldn't be running nightly builds at all.

Different levels of caring about their browser -- enough to download a nightly, not enough to read sprawling newsgroup threads with good arguments on either side. And I do think it's quite possible to use 64-bit Windows nightlies and file useful, helpful bugs even without needing prioritized understanding, for the most part.

Jeff

[Philip Chee]

This sounds ideal for A/B Testing by the Metrics team. Half the people
with Windows 64-bit landing on that page get a modified page with all 64
bit builds in a separate section down at the bottom below the fold.

Phil

--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.

[JP Rosevear]

On Thu, 2012-03-01 at 10:34 -0800, Asa Dotzler wrote:
> On 3/1/2012 10:02 AM, Chris Peterson wrote:
> > On 3/1/12 1:33 AM, Henri Sivonen wrote:
> >> If Chrome ships 64-bit on Windows, too, Firefox will look like its
> >> lagging even more badly. At that point, saying that we measured this
> >> or that won't matter for mindshare.
> >
> > Many early adopters are leaving Firefox for Chrome. Shipping a 64-bit
> > Firefox before Chrome (even as a non-default install) would give these
> > trendsetting users a reason to choose (and evangelize) Firefox.
>
> I'd like to understand why you believe that. Do we have any data saying
> that users want or need 64-bit Firefox?

Given that half of our nightly users are choosing to use the 64-bit
version, I think we can imply some of the "want" at least. You could
argue that the numbers are inflated because users are simply match their
OS capabilities, but its hard to imagine its only this.

-JP
--
JP Rosevear <j...@mozilla.com>
Mozilla

[Ron Hunter]

Running 32 bit software on a 64 bit machine is rather like emulating a
1401 on a 360-30, and then emulating the 360-30 emulating the 1401 on a
360-40, which I did back in the late 1960s. If we don't seem to be
keeping up with the hardware, we will be perceived as not up to date.

[James May]

Except for the fact that it's nothing like that.

[lordkit...@gmail.com]

i am serious guys, why not just make 64 bit i higher priority? 64bit is in large use and most computers ship with a 64bit os now. if you take a look at the steam hardware survey http://store.steampowered.com/hwsurvey/ you will see that win7 64bit is the most popular with almost half of the entire survey being win7 64. and its common for the users to have more then 2GB ram.

it's clear that there is a market for it, and lets face it if you ship 64bit most users will say "oh hey look 64bit is better then 32bit we better go use Firefox 64bit" so really you have the opportunity to jump on this and grab a bunch of users away from other browsers. So why are you trying so hard not too?

[Brian Smith]

Again, NSS has no testing at all on Win64. The NSS test suite does not run as part of the mozilla-central test suite, and there are no Win64 NSS tinderboxes I do not know if NSS is the only component that has this problem, but it is an important one. If we decide not to support Win64 then we shouldn't do the additional work to support NSS on Win64, and we should stop distributing the Win64 builds. But, if we do want to support Win64, then we should make testing NSS on Win64 a higher priority.

It would be very helpful to know which course of action to take soon.

Cheers,
Brian

[Nicholas Nethercote]

I think we've analyzed this to death. My gut feeling has shifted to
the "hell, let's just do it" side, i.e. support 64-bit windows.

- It eliminates a whole class of crashes (out of virtual memory).

- It'll let us steal a march on Chrome, or at least, not fall behind.

- We're going to have to do it some day, so why not now?

Nick

[Ron Hunter]

Not in reality, but when it comes to marketing, perception is everything.

[Asa Dotzler]

(I encourage anyone who hasn't to read the threads in this group titled
"Re: Firefox 64-bit for Windows: data gathering" and "Firefox 64-bit for
Windows: what we know")

A couple of why nots from the previous threads on this.

• 64-bit Firefox will, in most cases, use more more memory than 32-bit
Firefox.
• Our 32-bit JITs are a bit better than the 64-bit ones.
• User confusion about which Firefox build to use.
• User confusion about what plug-ins and add-ons work with 64-bit Firefox.
• Binary add-ons will be incompatible with 64-bit builds. This will
affect various software which install 32-bit binary add-ons, such as AV
products, etc.
• Maintaining another build/port means more build/test/qa infrastructure
and effort.
• Few NPAPI plug-ins are available in 64-bit and Windows offers no
solution for "universal binaries" so we can't easily mitigate this the
way we do with the 32-64 Mac binary.
• We don't have comparative stability and performance data between
32-bit and 64-bit Firefoxen on 64-bit and 32-bit Windows
• Could break our accessibility story completely (Applications which
work by hooking DLLs into Firefox's address space will no longer work
with 64-bit versions.)

- A

[Nicholas Nethercote]

On Sun, Mar 4, 2012 at 5:56 AM, Asa Dotzler <a...@mozilla.org> wrote:
>
> • 64-bit Firefox will, in most cases, use more more memory than 32-bit
> Firefox.

But those running 64-bit capable machines are likely to have more RAM installed.

> • Our 32-bit JITs are a bit better than the 64-bit ones.

> • Maintaining another build/port means more build/test/qa infrastructure and
> effort.

> • We don't have comparative stability and performance data between 32-bit
> and 64-bit Firefoxen on 64-bit and 32-bit Windows

Yep, it'll require work on our side.

> • Binary add-ons will be incompatible with 64-bit builds.  This will affect
> various software which install 32-bit binary add-ons, such as AV products,
> etc.

> • Few NPAPI plug-ins are available in 64-bit and Windows offers no solution
> for "universal binaries" so we can't easily mitigate this the way we do with
> the 32-64 Mac binary.

> • Could  break our accessibility story completely (Applications which work
> by hooking DLLs into Firefox's address space will no longer work with 64-bit
> versions.)

It'll require work by third parties, too. If we don't ever provide
64-bit releases, those third parties have no incentive (or ability) to
do that work.

> • User confusion about which Firefox build to use.
> • User confusion about what plug-ins and add-ons work with 64-bit Firefox.

We could keep 32-bit as the default. We could even distribute 64-bit
builds only on Nightly/Aurora/Beta, and label it clearly as
experimental, and that people should use 32-bit unless they know what
they're doing.


I still think this is the most compelling argument:

>> - We're going to have to do it some day, so why not now?

Unless people think that never doing a 64-bit Windows release is an
option -- but I don't think anyone's been arguing that -- I don't see
much point in delaying. Even if we don't start working assiduously on
it right now, turning off existing builds would effectively undo a
bunch of work that Armen and others did, and seems like a bad idea.

How about we keep the 64-bit Nightly builds available but add a big
label to the download page indicating that they're experimental,
possibly slower, plug-ins might not work, etc. The builds will then
get some testing, which will provide some impetus towards getting them
in a better state.

Nick

[Omega X]

I really don't see the point in discriminating against 64-bit Firefox on
Windows in this fashion unless the plan is to eliminate 64-Bit support
across all platforms.

--
==================================
~Omega X
MozillaZine Nightly Tester

[Asa Dotzler]

On 3/3/2012 1:58 PM, Omega X wrote:
> On 3/3/2012 12:56 PM, Asa Dotzler wrote:
>> On 3/2/2012 10:22 PM, Nicholas Nethercote wrote:
>>> I think we've analyzed this to death. My gut feeling has shifted to
>>> the "hell, let's just do it" side, i.e. support 64-bit windows.
>>>
>>> - It eliminates a whole class of crashes (out of virtual memory).
>>>
>>> - It'll let us steal a march on Chrome, or at least, not fall behind.
>>>
>>> - We're going to have to do it some day, so why not now?
>>
>> (I encourage anyone who hasn't to read the threads in this group titled
>> "Re: Firefox 64-bit for Windows: data gathering" and "Firefox 64-bit for
>> Windows: what we know")

> I really don't see the point in discriminating against 64-bit Firefox on
> Windows in this fashion unless the plan is to eliminate 64-Bit support
> across all platforms.

You clearly didn't read, as I suggested, the previous threads where
you'd have learned that Windows 64-bit differs from Mac 64-bit in
significant and meaningful to this discussion ways.

I could repeat everything that was covered in those prior threads but
I've got more important things to be doing so I encourage you to go read
read them and pay particular attention to the distinctions between
Windows and Mac 32-bit plug-ins in 64-bit builds parts.

- A

[Asa Dotzler]

And each of these items and their possible mitigation and related work
were discussed in the two previous threads. I'd rather not re-argue all
of those points so while your responses are legitimate, they don't offer
any new compelling information that wasn't already covered.

> I still think this is the most compelling argument:
>
>>> - We're going to have to do it some day, so why not now?
>
> Unless people think that never doing a 64-bit Windows release is an
> option -- but I don't think anyone's been arguing that -- I don't see
> much point in delaying. Even if we don't start working assiduously on
> it right now, turning off existing builds would effectively undo a
> bunch of work that Armen and others did, and seems like a bad idea.
>
> How about we keep the 64-bit Nightly builds available but add a big
> label to the download page indicating that they're experimental,
> possibly slower, plug-ins might not work, etc. The builds will then
> get some testing, which will provide some impetus towards getting them
> in a better state.

Yes. Thank you for going into more detail here. I agree with most of
these two paragraphs except the delaying part :-)

I may not have been clear in my previous reply. It was not meant to be a
"never do it because there's too much work" but rather a response to the
specific question of "why not now?" A simpler reply from me would have
said "because it's a non-trivial project and, IMO, we have more
important things to do right this moment."

I plan on posting a recommendation from the Product Team this week. I do
think we will eventually do a 64-bit release. That being said, I don't
think it should be a priority right now given the many other things
we've got on our plate. I agree that we should not throw out the work
that we've done to get builds going and available for nightly testing.
More to come :-)

- A

[Henri Sivonen]

On Sat, Mar 3, 2012 at 8:56 PM, Asa Dotzler <a...@mozilla.org> wrote:
> • 64-bit Firefox will, in most cases, use more more memory than 32-bit
> Firefox.

Yet we ship 64-bit on Mac.

> • Our 32-bit JITs are a bit better than the 64-bit ones.

Since our Mac and Linux users already run 64-bit, it could be
worthwhile to make the 64-bit JITs better.

> • Binary add-ons will be incompatible with 64-bit builds.  This will affect
> various software which install 32-bit binary add-ons, such as AV products,
> etc.

Seems like in the short term that would be an awesome feature. Less
crashware in the Firefox process FTW!

> • Maintaining another build/port means more build/test/qa infrastructure and
> effort.

But we do believe we'll have to go 64-bit on Windows eventually, right?

> • Few NPAPI plug-ins are available in 64-bit and Windows offers no solution
> for "universal binaries" so we can't easily mitigate this the way we do with
> the 32-64 Mac binary.

The really important one is Flash Player. That's available now. The
runners up are Silverlight and Java. PDF.js takes care of Acrobat.

How far along the long tail do you want to go?

Are we really going to tell Adobe, MS and Oracle now that they've done
the work to go 64-bit, we don't bother to follow up with a 64-bit
Firefox?

> • We don't have comparative stability and performance data between 32-bit
> and 64-bit Firefoxen on 64-bit and 32-bit Windows

Turning off 64-bit builds now would ensure we wouldn't get that data.

> • Could  break our accessibility story completely (Applications which work
> by hooking DLLs into Firefox's address space will no longer work with 64-bit
> versions.)

Seems like a reason to keep 32-bit builds available until ATs fix
their stuff. They aren't going to fix their stuff until we ship
64-bit.

[Ed Morley]

Thank you for all of the responses so far.

Just to clarify, my motivations for starting this thread were:

1) That I believe we're not giving Nightly users sufficient information to make an *informed* decision for 32 vs 64-bit. We seem to have agreement on this - I'll file a bug to get nightly.mozilla.org adjusted.

2) To highlight that there seems to be quite a discrepancy between the Win64 test coverage some people *think* we have - and reality. We need to either run (unhidden) Win64 tests on most/all trees or might as well run them on none at all. Carrying on as we are, halfway between the two options is just giving ourselves false reassurances of maintaining the status quo, whilst still happily wasting machine/releng time.


As an example of #2, even in this thread there have been comments along the lines of "seems unwise to stop running tests/builds and undo all the work done so far" - when my point is that we're *already* undoing Armen's hard work. All the tests are hidden and Win64 build failures often left un-starred - so who knows what is breaking that we haven't even noticed.

I'm also concerned that we may already be losing users (from the 50% of Nightly Windows users on Win64), due to the recent 80% + 30% JS regressions (see first post in this thread for regression details). Whilst a proportion of them may of course be using Win64 builds just to avoid running out of address space with hundreds of tabs *and* be fully aware of the current performance drawbacks, I'm betting many of them aren't. Therefore, when their "superior"/shiny Win64 Nightly builds start performing badly compared to say Chrome dev-channel.latest, why would they have any reason to not just blame Firefox in general and just switch to another browser? Anyway, hopefully this can be avoided by the nightly.mozilla.org changes + a bit of mozillaZine/tech blog outreach.

I eagerly await the recommendation from the Product Team that Asa will be bringing to us this week, so that we may start acting on some of the issues raised so far - and most importantly make our Win64 position (whatever it may end up being) clearer for sheriffs, releng, devs and our Nightly users.


Ed

[Chris Cooper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12-03-05 12:43 PM, Ed Morley wrote:
> I eagerly await the recommendation from the Product Team that Asa
> will be bringing to us this week, so that we may start acting on
> some of the issues raised so far - and most importantly make our
> Win64 position (whatever it may end up being) clearer for sheriffs,
> releng, devs and our Nightly users.

This. ^^

RelEng has been in a holding pattern WRT Win64 support since Armen got
the coverage set up. We're quite happy to provide/figure out the
hardware support provided Win64 is acknowledged as a priority so we
can make a *conscious choice* about support relative to other projects.

cheers,
- --
coop
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPVQTIAAoJEGVzgtv/JREKZfcH/ij/HTZ7i40yeMrUHxfHLVba
bRFsxG1bWV7cnHEnd3RuPiKPByYm8iUbiG5ZRCTaZNZ7ufsPk+eAg2QA+nc3RRg/
vKTe8JgIsYDI//A+VZuITUzW9aEUZ9EmK7AYVtm6ECKtVEVW04v+oSIKoTypeUta
O8uMVJUyybimjhKL6etzZlmLfpcsySCWa2GJbVd1IQSG33SoCa6cFT9DeQibOhEh
4OdqsGEf9qi+3siOpEma3hINO261+DU857FsSLVoCDlKYjgdQW6tv+J7AbP1g3Bt
d8YtCJ/mmtgtev+/jcWO/gc7Pre85eDFbyjEdEKx4crD8vdi1v7jcvGfbJGnfk4=
=ciLE
-----END PGP SIGNATURE-----

[Dave Mandelin]

On Monday, March 5, 2012 4:46:12 AM UTC-8, Henri Sivonen wrote:
> On Sat, Mar 3, 2012 at 8:56 PM, Asa Dotzler <a...@mozilla.org> wrote:
> > • 64-bit Firefox will, in most cases, use more more memory than 32-bit
> > Firefox.
>
> Yet we ship 64-bit on Mac.
>
> > • Our 32-bit JITs are a bit better than the 64-bit ones.
>
> Since our Mac and Linux users already run 64-bit, it could be
> worthwhile to make the 64-bit JITs better.

Btw, IonMonkey is already doing this: it has equal support for x86, x64, and ARM.

[Dave Mandelin]

On Monday, March 5, 2012 4:46:12 AM UTC-8, Henri Sivonen wrote:

> On Sat, Mar 3, 2012 at 8:56 PM, Asa Dotzler <a...@mozilla.org> wrote:
> > • 64-bit Firefox will, in most cases, use more more memory than 32-bit
> > Firefox.
>
> Yet we ship 64-bit on Mac.
>
> > • Our 32-bit JITs are a bit better than the 64-bit ones.
>
> Since our Mac and Linux users already run 64-bit, it could be
> worthwhile to make the 64-bit JITs better.

[Ed Morley]

On Monday, 5 March 2012 17:43:51 UTC, Ed Morley wrote:
> [...] I'll file a bug to get nightly.mozilla.org adjusted.

Have filed bug 733206.

Ed

[Hubert Figuière]

On 03/03/12 10:56 AM, Asa Dotzler wrote:
> • Could break our accessibility story completely (Applications which
> work by hooking DLLs into Firefox's address space will no longer work
> with 64-bit versions.)

Concerning Accessibility, we are dependent on this bug
https://bugzilla.mozilla.org/show_bug.cgi?id=606468

And there are possibly other issues with the screen reader as Asa
mentionned.

Not that this should stop you from doing it, but this should be known.

Hub

[Philip Chee]

Given that JIT performance is one of the key blockers to supported 64bit
Windows builds, how close are we to rolling out IanMonkey to production?

[dvander]

On Mar 5, 5:30 pm, Philip Chee <philip.c...@gmail.com> wrote:
> On 5 Mar 2012 11:21:14 -0800 (PST), Dave Mandelin wrote:
>
> > On Monday, March 5, 2012 4:46:12 AM UTC-8, Henri Sivonen wrote:
> >> On Sat, Mar 3, 2012 at 8:56 PM, Asa Dotzler <a...@mozilla.org> wrote:
> >> > • 64-bit Firefox will, in most cases, use more more memory than 32-bit
> >> > Firefox.
>
> >> Yet we ship 64-bit on Mac.
>
> >> > • Our 32-bit JITs are a bit better than the 64-bit ones.
>
> >> Since our Mac and Linux users already run 64-bit, it could be
> >> worthwhile to make the 64-bit JITs better.
>
> > Btw, IonMonkey is already doing this: it has equal support for x86, x64, and ARM.
>
> Given that JIT performance is one of the key blockers to supported 64bit
> Windows builds, how close are we to rolling out IanMonkey to production?
>
> Phil
>

There are still unknowns, so I'd like to not commit to a date here :)
but we're expecting to land IonMonkey 2-3 months from now, if there
are no problems.

For what it's worth, our current JIT performance is not unacceptable
on x64. At its worst, it's maybe 15% slower than x86, but it depends
on the benchmark.

-David

[Ed Morley]

On Monday, 5 March 2012 17:43:51 UTC, Ed Morley wrote:
> [...] I'll file a bug to get nightly.mozilla.org adjusted.

Bug 733206 is now complete - the Win64 Nightly builds are now no longer directly shown on http://nightly.mozilla.org/ (thanks tofumatt). Users still wishing to download them, can use the intentionally more subtle "Other Nightly Builds (FTP)" footer link.

Ed

[Matt Schnackenberg]

On Mar 11, 8:42 pm, Ed Morley <bmo.takethis...@edmorley.co.uk> wrote:
> On Monday, 5 March 2012 17:43:51 UTC, Ed Morley  wrote:
> > [...] I'll file a bug to get nightly.mozilla.org adjusted.
>

> Bug 733206 is now complete - the Win64 Nightly builds are now no longer directly shown onhttp://nightly.mozilla.org/(thanks tofumatt). Users still wishing to download them, can use the intentionally more subtle "Other Nightly Builds (FTP)" footer link.
>
> Ed

I completely disagree with that move, as well as the entire notion
that the 64bit version is inferior. I have been using the 64bit
Nightly since the beginning as my main browser with zero issues. I do
not use Firefox 32bit, and never plan to again. A 64bit installer will
not install on a 32bit OS, therefore if a person is illiterate enough
to not read "32bit" and "64bit" under each download, they can go back
to the page and download the other link if they screwed up. Also, I
have 8GBs of DDR3 ram, so I am not limited to the 3.7GBs that Win32
users are.

Also, not supporting Win64 is becoming stupid. 64bit OSs like Windows
7 have a strong foothold and eating away at 32bit OS market-share.

According to the PC game company Valve's February 2012 hardware survey
43.02% of there 20+ million users use Windows 7 64bit versus Windows 7
32bit at 9.01%. Vista 64bit is at 13.12% versus Vista 32 at 11.50%.
Both 64bit OSs increased usage between the January survey and February
survey.

http://store.steampowered.com/hwsurvey

[Ed Morley]

On Thursday, 15 March 2012 17:26:03 UTC, Matt Schnackenberg wrote:
> I completely disagree with that move, as well as the entire notion
> that the 64bit version is inferior.

The Win64 Nightly has many more disadvantages than advantages at present. My initial post in this thread covered some of them:
https://groups.google.com/d/msg/mozilla.dev.planning/Giij-AZfUAM/XFtqZGJjnQ8J

For the full list, see:
https://groups.google.com/d/topic/mozilla.dev.planning/Mrba6hvl5-w/discussion
https://groups.google.com/d/topic/mozilla.dev.planning/aeTXSZ_WFAs/discussion

Bear in mind that Win64 Nightly builds are still being produced (and people using them will still get updates) - we've just made them less visible. You can download them from the "Other Nightly Builds (FTP)" footer link on nightly.mozilla.org.

> A 64bit installer will
> not install on a 32bit OS, therefore if a person is illiterate enough
> to not read "32bit" and "64bit" under each download, they can go back
> to the page and download the other link if they screwed up.

The link being removed from nightly.mozilla.org had nothing to do with 32-bit Windows users accidentally downloading an incompatible version of Nightly. Please see the discussion in bug 733206 & the rest of this thread.

> Also, not supporting Win64 is becoming stupid. 64bit OSs like Windows
> 7 have a strong foothold and eating away at 32bit OS market-share.

No one is disputing that the market share of 64-bit versions of Windows is increasing. What was under discussion was the pros and cons of the current (slower, untested, proven regression-prone) Win64 Nightly builds, when compared side by side with the 32-bit Nightly on a 64-bit version of Windows.

Kind regards,

Ed

[David Rajchenbach-Teller]

On 2/28/12 11:07 PM, James May wrote:

> Isn't there some benefit with more room for ASLR and something about the
> calling convention being better?

Actually, I think that ASLR is only 32 bits for Windows <= 7, even on 64
bit platforms. And even for Windows 8, going 64 bits with ASLR requires
some special flag.

Cheers,
David

--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla

[lordkit...@gmail.com]

Alright so the 64bit nightly is currently slower UNTESTED and proven to be regression prone and your response is to make it more difficult to find? everyone using nightly builds is fully aware that they can and most likely will be slower, less stable, and overall buggy compared to the stable builds. The reason we use them IS TO HELP YOU TEST THEM, so by making the 64bit no longer on the main page you have alienated about a good 80% of your users that used it imo, most people will not have read this thread and even less will assume 64bit has just been moved when they see its not on the main page anymore.

This is just plain silly and stupid imo, the point of nightly is to test things not to worry about which is faster, if this was an argument over stable release i would side with you 100% but this is nightly, its not even beta its not alpha we already have those this is nightly the ultra supar new most likely broken as shit build who cares if the 64bit is slower by removing it from main page you are completely removing its ability to be tested and later improved upon

[je...@stikman.com]

Of course Mozilla wants their software tested, that is the whole point of Nightly, Aurora, and Beta builds. The problem is they do not have the resources right now to devote to fixing the issues with the 64-bit builds. Why make a build easily accessible if the bugs in that particular version of the software is not going to get fixed anytime soon? That will end up pissing more people off and giving Mozilla bad press. Right now they can only spend time on fixing issues in the 32-bit builds, so those are the builds that are easily accessible and available.

When they have more time to devote to 64-bit builds, they will be more easily accessible and a broader test base will be encouraged.

Jeff

[Andrew Penhorwood]

Mozilla is missing a great opportunity here. Soon 64Bit builds of any software will be viewed as the best and latest no matter what the developers say. Once the mindset of 64 bits are better (already starting to happen in some circles) not having a quality build of 64bit Firefox on any platform will give up market share to other browsers. Something that most likely can't be reversed quickly.

[Jeff Grossman]

On Friday, March 30, 2012 7:12:20 AM UTC-7, Andrew Penhorwood wrote:
> Mozilla is missing a great opportunity here. Soon 64Bit builds of any software will be viewed as the best and latest no matter what the developers say. Once the mindset of 64 bits are better (already starting to happen in some circles) not having a quality build of 64bit Firefox on any platform will give up market share to other browsers. Something that most likely can't be reversed quickly.

Yes, I do agree with that. Almost all, if not all, computers now come with a 64-bit operating system. Users will start to say, why am I running a 32-bit application on my new 64-bit operating system. That must be slower, so I better move to a 64-bit application.

But, what bugs will not get fixed or new features will not be implemented because the Mozilla developers are working on fixing the 64-bit issues? The 64-bit version is clearly not at the same quality level as the 32-bit version is.

Jeff

[lordkit...@gmail.com]

only because the same time has not been put into it (imo) you cant honestly tell me that 32bit firefox was never at that point maybe early on in its life? well 64bit is a new build and tbqh mozilla is being rather stupid (imo) by not dedicating most of their time to getting the 64bit build up to par with the 32 and getting it ready for release, 64 bit os are taking over. And you have a chance to get more users just by making firefox say 64bit on it even if it doesnt really do anything. Mind you i am sure there are at least some things that 64bit could do better than 32bit but the main point is the 64bit wave is coming and i would hate to see mozilla lagging behind on it.

from what i have read in this thread apparently 64bit is actually missing a lot of things compared to 32bit and supposedly supar buggy, and yet i have been using it as my main browser since it showed up on the nightly page and have not once had a major issue past the rare and occasional time when the latest update makes an error that makes it crash on start-up but the fix is generally released already or within an hour of it happening. And i use my browser rather extensively more so then most people i would feel safe in saying, yet no issues, no random bugs or anything,

also where are these missing features? or should i say what are they because so far i dont notice anything missing compared to when using a 32bit build. I still have all my addons and they all work perfectly fine, all the menu options appear to be there as well, honestly i dont know why mozilla seems to be so resistant to going full time with 64-bit do you have any reason other than "just cause" or "too much work" a reason that makes sense to not get going on this when its clearly ready to go full time and wanted?

[James May]

> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>

With some clever marketing it can be mitigated significantly, IMHO. eg.
branding the download as "Universal", "64 bit ready", "better on 64bit"* or
something similar.

I also think it's possible that you're overstating the extent to which
people notice such things.

-- James

*all of which are true, 32 bit builds can use twice as much address space
on x64.

[lordkit...@gmail.com]

alright so you guys have already lost some people, i had a few of my friends reinstall windows and when i noticed they now had opera instead of firefox i asked why and they said "the 64bit nightly inst offered anymore so i went to opera since they have one" and when i told them its just under other builds they came back a few min later saying "there are too many folders and i cant find it ill just stay with opera" so way to go guys your already loosing people good call!