Firefox 64-bit for Windows 7

We've been making 64-bit builds of Firefox for Windows for some time now
but they're not "official" so they don't receive the full development,
testing, or release support that our 32-bit Windows build gets. They're
"unofficial" as it were.

Mozilla is evaluating the pros and cons of maintaining and shipping an
official 64-bit version and so I'm reaching out to you all for further*
input on the subject.

Here's what I've gathered so far. If you can add to this or offer
corrections, that'd be really helpful.

Advantages:
• With more registers, Firefox users on a 64-bit build could see fewer
out of memory crashes (actually, out-of-virtual-address-space crashes.)
This advantage could be somewhat mooted if we chase stability wins
elsewhere.
• Performance could be better. Compute-intensive things that fit
entirely in cache might get faster. Performance could be improved with
other efforts, though.
• Better security. The address space layout can be randomized far more
effectively when you have 2^64 address space to work with.


Disadvantages:*
• 64-bit Firefox will, in most cases, use more more memory than 32-bit
Firefox. This could be mitigated by improved memory usage across all
builds.
• Our 32-bit JITs are a bit better than the 64-bit ones. This could be
mitigated by putting more effort into optimizing the 64-bit jits.
• User confusion about which Firefox build to use. This could be
mitigated with a stub installer or defaulting to 32-bit unless users
explicitly went seeking out 64-bit Firefox for Windows builds.
• User confusion about what plug-ins and add-ons work with 64-bit
Firefox. This might take shared work from Mozilla and plug-in vendors.
• Maintaining another build/port means more build/test/qa infrastructure
and effort. I'm not sure how this could be mitigated. We have already
put some of the build and test infrastructure in place.
• 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.  This could be mitigated if
Mozilla's official support for a 64-bit Firefox on Windows 7 encouraged
plug-in vendors to increase their efforts around 64-bit. This could also
be mitigated by building a version that could fall-back to 32 bit
plug-ins. That's a lot of work though and a resource conflict with E10S.


Additional info:
• Flash, Java, and Silverlight all have 64-bit Windows NPAPI plug-ins,
though at differing levels of completeness I believe.
• About half of win7 users are on 64-bit versions. That may not sound
like much, but it's about 2X our Mac and Linux users combined.
• We don't have comparative performance data between 32-bit and 64-bit
Firefox on the same hardware. I think we need that.
• Competitively, IE9 doesn't ship an official 64-bit build and the
unofficial one doesn't have a modern JS** implementation. Chrome also
does not support 64-bit on Windows*** or Mac.

So, the three potential wins are stability, performance, and security.
The downsides are user confusion, memory usage, plug-in availability,
and resource costs.

Does this paint a fair picture? What am I wrong about or missing?

- A


*
http://weblogs.mozillazine.org/asa/archives/2011/07/questions_about_64bi.html
** http://zd.net/p7hObC
*** http://code.google.com/p/chromium/issues/detail?id=8606

Would it be feasible to add a "thunking" layer that supports 32-bit
plugins inside 64-bit Firefox?

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

John Hopkins wrote:
> On 11-10-17 03:20 PM, Asa Dotzler wrote:
>> Disadvantages:*
>> • 64-bit Firefox will, in most cases, use more more memory than 32-bit
>> Firefox. This could be mitigated by improved memory usage across all
>> builds.
>> • Our 32-bit JITs are a bit better than the 64-bit ones. This could be
>> mitigated by putting more effort into optimizing the 64-bit jits.
>> • User confusion about which Firefox build to use. This could be
>> mitigated with a stub installer or defaulting to 32-bit unless users
>> explicitly went seeking out 64-bit Firefox for Windows builds.
>> • User confusion about what plug-ins and add-ons work with 64-bit
>> Firefox. This might take shared work from Mozilla and plug-in vendors.
>
> Would it be feasible to add a "thunking" layer that supports 32-bit
> plugins inside 64-bit Firefox?
>
> John

John, feasible? Yes, I think so. Worth it, when looking at where those
resources would have to come from? I don't think so.

I'm starting off with the assumption, from the Product Team's
perspective, that this is really only worth it if it doesn't come with a
huge burden of new code to handle 32-bit plug-ins. The people who could
help with that are already committed to our multi-process work, a very
high priority for the Product Team, and I wouldn't change the priority
on that to try to get 32-bit plug-ins in a 64-bit Firefox.

- A

> Advantages:
> • With more registers, Firefox users on a 64-bit build could see fewer out
> of memory crashes (actually, out-of-virtual-address-space crashes.) This
> advantage could be somewhat mooted if we chase stability wins elsewhere.

You're confusing a few concepts here.

1. With more registers, _many functions will run faster_, because the
compiler doesn't have to spill as many variables to the stack (or
recompute their values).

2. With a larger virtual address space, users will see fewer
out-of-memory crashes.

** This advantage is somewhat offset by the terrible swapping that can
occur when you run out of physical RAM and need to continue GCing.

** This advantage could be somewhat mooted by reducing per-process
memory use in other ways (memshrink, e10s) and giving users tools to
reduce tab use (reading list, send to mobile).

** This advantage would complement other efforts to improve Firefox's
stability. (As we fix non-OOM crashes, OOM crashes will increase due
to longer and larger sessions.)

Do we have stats on how many of our crashes on Windows are due to OOM?
With https://bugzilla.mozilla.org/show_bug.cgi?id=493779 fixed, we
should be able to figure this out.

Jesse, thanks for the clarification. I was trying to assemble data from
a few different discussions and comments and I admit to not
understanding all of it. I appreciate your helping me not propagate
confusing and or wrong information.

I also agree that we need more data on this. I expect we'll be able to
get comparative performance data but you're right, we need more info on
Memory-related crashes to make intelligent decisions on potential
stability wins.

- A

Hi, John.
Big problem is build issue.  I have a code for supporting x86 plug-in on
Win64, but it is no good idea to resolve build issue.

Current plugin-container architecture requires xul.dll, so, we need over
5 hours to build packages.


-- Makoto

Hi, Asa.

Now, all automation tests are passed on Win64 build.  Except to method
JIT, x64 will be faster than x86.  Also, even if Linux x86-64 (current
tier-1), JIT is slower than x86.

And, since accessibility DLL becomes 64-bit, any issue may occurs.


-- Makoto

On 10/17/11 9:28 PM, Makoto Kato wrote:
> Except to method JIT, x64 will be faster than x86.

Sometimes.  Sometimes not.

It depends on how much cache pressure matters for the workload.  c.f.
https://twitter.com/#!/bz_moz/status/73784940755566592 (done on a
particular selector-matching workload on Mac).

> Also, even if Linux x86-64 (current tier-1), JIT is slower than x86.

Likewise on Mac.  We do just need to improve the x86-64 jits as needed.

-Boris

2011/10/17 Boris Zbarsky <bzba...@mit.edu>:

> On 10/17/11 9:28 PM, Makoto Kato wrote:
>>
>> Except to method JIT, x64 will be faster than x86.
>
> Sometimes.  Sometimes not.
>
> It depends on how much cache pressure matters for the workload.  c.f.
> https://twitter.com/#!/bz_moz/status/73784940755566592 (done on a particular
> selector-matching workload on Mac).

I didn't know about the cache pressure bit, but I just want to point
out that in most cases where an application is slower in 64bit than in
32bit mode, the reason is usually that it's using explicitly 32-bit
integers as array offsets. For example our nsTArray class, using
PRUint32 as offsets, is probably slower in 64bit mode. And I'm sorry I
never got around to implementing the outcome of the discussion I
started a while ago,
http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/94a564192d4b4f71

Cheers,
Benoit

>
>> Also, even if Linux x86-64 (current tier-1), JIT is slower than x86.
>
> Likewise on Mac.  We do just need to improve the x86-64 jits as needed.
>
> -Boris

Asa Dotzler a écrit :
> John Hopkins wrote:
>> [...]

>> Would it be feasible to add a "thunking" layer that supports 32-bit
>> plugins inside 64-bit Firefox?
>

> [...] this is really only worth it if it doesn't come with a

> huge burden of new code to handle 32-bit plug-ins. The people who could
> help with that are already committed to our multi-process work, a very
> high priority for the Product Team, and I wouldn't change the priority
> on that to try to get 32-bit plug-ins in a 64-bit Firefox.

IMO, 32 bits plugin support is a must-have, and with out of process
plug-ins it won't be too much code.

So do multi-process first, and next 64-bit Windows can become something
else than a curiosity.

Asa Dotzler a écrit :

> • With more registers, Firefox users on a 64-bit build could see fewer
> out of memory crashes

More memory space actually.

> [...]

> • Our 32-bit JITs are a bit better than the 64-bit ones. This could be
> mitigated by putting more effort into optimizing the 64-bit jits.

But there's indeed more registers available in 64 bits mode, not just
more memory, and  with more registers available it's theorically much
easier to write an efficient JIT. Which means than with some efforts
there's every reason why the 64 bits JIT should be faster than the 32
bits one.

On 10/18/11 3:43 AM, Jean-Marc Desperrier wrote:
> IMO, 32 bits plugin support is a must-have, and with out of process
> plug-ins it won't be too much code.

I don't follow this.  We have out of process plug-ins on Windows right
now.  But the point is that the process that runs the plug-in is the
same binary that runs the browser itself, and if the latter becomes
64-bit then it can't run 32-bit plug-ins.

So what exactly is your "not too much code" proposal?

-Boris

On 10/18/11 3:53 AM, Jean-Marc Desperrier wrote:
> But there's indeed more registers available in 64 bits mode, not just
> more memory, and with more registers available it's theorically much
> easier to write an efficient JIT. Which means than with some efforts
> there's every reason why the 64 bits JIT should be faster than the 32
> bits one.

It _really_ depends on the code and workload.

Yes, there are more registers available.  I already mentioned that there
is also more cache pressure.  The other thing I've seen in terms of the
jit is that sometimes 64-bit code requires more instructions to do the
same thing as 32-bit code.  For example, loading a value from a
compile-time-constant memory location into a register can be done in one
instruction in 32-bit code but needs two instructions in 64-bit code
(because you can't have a 64-bit immediate in a lea instruction, so you
have to load the address into a register first on 64-bit).  And this
does matter in practice, because the pointer to the global is
compile-time-constant, so various things involving the global object
turn into precisely such loads.  I've seen testcases on which our 32-bit
jit beat our 64-bit one, and the only difference was that the 64-bit
code had to run more instructions due to this issue.

So the upshot is that making blanket performance claims about what
"should" be faster isn't all that useful.  We can probably make the
64-bit jit faster for some workloads.  We probably can't make it faster
for others.  What's not obvious is which workloads we have more of (and
benchmarks may or may not help here, depending on how well they match
the characteristics of real-life code).  The only way to get anything
other than wild speculation here is to measure, profile, optimize,
measure again....

-Boris

On Tue, Oct 18, 2011 at 07:54:39AM -0400, Boris Zbarsky wrote:
> On 10/18/11 3:53 AM, Jean-Marc Desperrier wrote:
> >But there's indeed more registers available in 64 bits mode, not just
> >more memory, and with more registers available it's theorically much
> >easier to write an efficient JIT. Which means than with some efforts
> >there's every reason why the 64 bits JIT should be faster than the 32
> >bits one.
>
> It _really_ depends on the code and workload.
>
> Yes, there are more registers available.  I already mentioned that
> there is also more cache pressure.  The other thing I've seen in
> terms of the jit is that sometimes 64-bit code requires more
> instructions to do the same thing as 32-bit code.  For example,
> loading a value from a compile-time-constant memory location into a
> register can be done in one instruction in 32-bit code but needs two
> instructions in 64-bit code (because you can't have a 64-bit
> immediate in a lea instruction, so you have to load the address into
> a register first on 64-bit).

Depends if you need to load something that is far or not. You can use
addresses relative to the instruction pointer and have one instruction.

Mike

All,

While the engineering discussion is fascinating, I doubt it's actually
helping Asa get the answers that he's looking for in terms of knowing
whether his initial impressions were right. It sounds like it's not black
and white, and more importantly, like specific to our JIT the performance
gains are not completely guaranteed without further tuning.

Let's focus on answers Asa can use for the decision and planning he needs to
make, and allow him to ask follow ups if more detail is required. The
engineering debate about performance optimization can go in
mozilla.developer.platform and is likely to be more germane there..
especially if it's decided we need to invest in 64 bit optimizations!

thanks,
mike the moderator

On Tue, Oct 18, 2011 at 10:43 AM, Jean-Marc Desperrier <jmd...@gmail.com> wrote:
> IMO, 32 bits plugin support is a must-have

Why? Do we actually have data about what the long tail of plug-ins
looks like after the top ones that are or are soon going to be
64-bit-ready?

Do users even notice if silently-installed unsolicited plug-ins like
the Google Updater aren't loaded by Firefox? Does the QuickTime
Plug-in have use cases beyond watching Apple's own marketing videos
these days?

How rare are relatively unmaintained special-purpose NPAPI oddities
like extranet-specific authentication placebos?

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

On 18 October 2011 07:40, Boris Zbarsky <bzba...@mit.edu> wrote:

> I don't follow this.  We have out of process plug-ins on Windows right now.
>  But the point is that the process that runs the plug-in is the same binary
> that runs the browser itself, and if the latter becomes 64-bit then it can't
> run 32-bit plug-ins.
>
> So what exactly is your "not too much code" proposal?
>

Why not just a ship a 32-bit browser along with the 64-bit browser on
Windows, and run 32-bit plug-ins in a 32-bit browser, with ~ NPAPI IPC
bridge.

Ted tells me this is effectively what we are doing on OS X already.

Wes

--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102

Here are a couple more points to take into account.

*** Performance and asm code quality  ***

While I understand that 64bit is not a clear improvement in many
general-purpose situations, 64bit can become a much bigger improvement
in situations where we do floating-point computations. Such situations
include:
  - WebGL
  - Canvas 2D
  - Layout (CSS etc)
  - Probably Audio/Video stuff though I'm not sure

The reason is that SSE2, which is always available in 64bit mode, is
not just about SIMD, it also provides a replacement for old x87
floating-point arithmetic instructions. That means that even without
using SIMD, without any vectorization, just switching to 64bit code
instantly results in better asm code and better performance. I mean
potentially *much* better performance. For example, computing
dot-products is already 2x faster with scalar SSE2 instructions over
plain x87 (again, not even using SIMD), the reason being that in SSE2
one can run a multiplication and an addition in 1 cycle (a*b+c).

Note that i686 only has SSE1 which misses a lot of useful
instructions, for starters it doesn't support double precision. We can
use SSE2 in 32bit code but we would have to compile also a non-SSE2
path, which would mean bigger, more complex code, and which means we
can't just automatically benefit from it in the way we do in 64bit
mode.

The other big part of SSE2, of course, is SIMD.

I disagree with the notion that benefits of SSE2 benefits only
computations that fit entirely in the cache, for two reasons.

  A. First, a computation like

   for (i in huge array)
      result[i] = sin(array[i]);

Would benefit from SSE2 even if the array doesn't fit in cache,
because computing sin(x) is computation-intensive enough. Note it
would even benefit from SSE2-without-SIMD (what we get for free in
64bit mode) because implementing sin(x) can benefit a lot from SSE2's
1-cycle a*b+c operation.

  B. Second, computations whose time-complexity is greater than the
space-complexity, which is most interesting computations, can
typically reorganized for cache-friendliness if needed (example:
matrix product).

*** Stability ***

32bit means that Firefox will crash when its address space exceeds a
OS-dependent limit that's typically around 2 G. Not huge by today's
standards. People have 4G machines now and are running more and more
intensive computations in web pages, or have zillions of tabs. 64bit
means we'll never crash for that reason.

Cheers,
Benoit

2011/10/17 Asa Dotzler <a...@mozilla.com>:

I think I need to add two items to the disadvantages list:

* 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.
* Applications which work by hooking DLLs into Firefox's address space will
no longer work with 64-bit versions.  The most important example of this
type of application are accessibility clients.

Cheers,
--
Ehsan
<http://ehsanakhgari.org/>
> * http://weblogs.mozillazine.**org/asa/archives/2011/07/**
> questions_about_64bi.html<http://weblogs.mozillazine.org/asa/archives/2011/07/questions_about_64bi.html>
> ** http://zd.net/p7hObC
> *** http://code.google.com/p/**chromium/issues/detail?id=8606<http://code.google.com/p/chromium/issues/detail?id=8606>
> ______________________________**_________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/**listinfo/dev-planning<https://lists.mozilla.org/listinfo/dev-planning>
>

2011/10/18 Benoit Jacob <jacob....@gmail.com>:

> Here are a couple more points to take into account.
>
> *** Performance and asm code quality  ***
>
> While I understand that 64bit is not a clear improvement in many
> general-purpose situations, 64bit can become a much bigger improvement
> in situations where we do floating-point computations. Such situations
> include:
>  - WebGL
>  - Canvas 2D
>  - Layout (CSS etc)
>  - Probably Audio/Video stuff though I'm not sure
>
> The reason is that SSE2, which is always available in 64bit mode, is
> not just about SIMD, it also provides a replacement for old x87
> floating-point arithmetic instructions. That means that even without
> using SIMD, without any vectorization, just switching to 64bit code
> instantly results in better asm code and better performance. I mean
> potentially *much* better performance. For example, computing
> dot-products is already 2x faster with scalar SSE2 instructions over
> plain x87 (again, not even using SIMD), the reason being that in SSE2
> one can run a multiplication and an addition in 1 cycle (a*b+c).

Note: I'm not talking about a specific combined mul-add instruction
here, just the fact that Intel CPUs and I believe recent AMD cpus are
able to run both instructions in 1 cycle.

Benoit

Ehsan Akhgari wrote:
> I think I need to add two items to the disadvantages list:
>
> * 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.
> * Applications which work by hooking DLLs into Firefox's address space will
> no longer work with 64-bit versions.  The most important example of this
> type of application are accessibility clients.

Thanks, Ehsan, this is exactly the kind of feedback that will help us
make decisions.

- A

Benoit Jacob wrote:

> While I understand that 64bit is not a clear improvement in many
> general-purpose situations, 64bit can become a much bigger improvement
> in situations where we do floating-point computations. Such situations
> include:
>    - WebGL
>    - Canvas 2D
>    - Layout (CSS etc)
>    - Probably Audio/Video stuff though I'm not sure

Thanks, Benoit. This is really helpful new information. Do you know if
we have any tests that can demonstrate these gains on the current 64-bit
builds when compared to the current 32-bit builds?

- A

Ehsan tells me that I need to reduce the level of details in my email,
so here goes the executive summary:

The "we didn't measure a performance gain" approach to 64bit is
misguided for 2 reasons:

1) 64bit is a much bigger win for emerging use cases such as gaming
2) the bigger gains require code changes which we have yet to do
(SIMD) and likewise current performance problems can be easily fixed
by code changes which we need to do.

Benoit

2011/10/18 Benoit Jacob <jacob....@gmail.com>:

> 2011/10/18 Benoit Jacob <jacob....@gmail.com>:
>> Here are a couple more points to take into account.
>>
>> *** Performance and asm code quality  ***
>>

>> While I understand that 64bit is not a clear improvement in many
>> general-purpose situations, 64bit can become a much bigger improvement
>> in situations where we do floating-point computations. Such situations
>> include:
>>  - WebGL
>>  - Canvas 2D
>>  - Layout (CSS etc)
>>  - Probably Audio/Video stuff though I'm not sure
>>

Jean-Marc Desperrier wrote:
> Asa Dotzler a écrit :
>> • With more registers, Firefox users on a 64-bit build could see fewer
>> out of memory crashes
>
> More memory space actually.

Thanks, Jean-Marc, for the correction here. There is general agreement,
am I correct, that we should see fewer out of memory crashes with 64-bit
builds? I just got the explanation wrong?

- A

Makoto Kato wrote:
> Hi, Asa.
>
> Now, all automation tests are passed on Win64 build. Except to method
> JIT, x64 will be faster than x86. Also, even if Linux x86-64 (current
> tier-1), JIT is slower than x86.
>
> And, since accessibility DLL becomes 64-bit, any issue may occurs.


Makoto, is your concern about the 64-bit accessibility DLL that we will
break accessibility tools, or something else?

- A

Jean-Marc Desperrier wrote:
> Asa Dotzler a écrit :
>> John Hopkins wrote:
>>> [...]
>>> Would it be feasible to add a "thunking" layer that supports 32-bit
>>> plugins inside 64-bit Firefox?
>>
>> [...] this is really only worth it if it doesn't come with a
>> huge burden of new code to handle 32-bit plug-ins. The people who could
>> help with that are already committed to our multi-process work, a very
>> high priority for the Product Team, and I wouldn't change the priority
>> on that to try to get 32-bit plug-ins in a 64-bit Firefox.
>
> IMO, 32 bits plugin support is a must-have, and with out of process
> plug-ins it won't be too much code.

Can you say more here? We've got some preliminary stats that suggest
we'll cover the overwhelming majority of users with Flash, Java, and
Silverlight.

We're trying to collect more complete data here with Telemetry so we can
get a better picture of the long tail.  I don't think we'd force the
64-bit Firefox on folks -- we might even say "don't download this if you
depend on plug-ins other than A, B, and C." or something like that.

- A

Henri Sivonen wrote:

> On Tue, Oct 18, 2011 at 10:43 AM, Jean-Marc Desperrier<jmd...@gmail.com>  wrote:
>> IMO, 32 bits plugin support is a must-have
>

> Why? Do we actually have data about what the long tail of plug-ins
> looks like after the top ones that are or are soon going to be
> 64-bit-ready?
>
> Do users even notice if silently-installed unsolicited plug-ins like
> the Google Updater aren't loaded by Firefox? Does the QuickTime
> Plug-in have use cases beyond watching Apple's own marketing videos
> these days?
>
> How rare are relatively unmaintained special-purpose NPAPI oddities
> like extranet-specific authentication placebos?

Henri, we can collect some great data here through Telemetry. I'll see
what can be done to increase the priority on gathering that data. I lean
towards not worrying too much about the long tail but better data could
definitely change my assumptions.

- A

Wes Garland wrote:
> On 18 October 2011 07:40, Boris Zbarsky<bzba...@mit.edu>  wrote:
>
>> I don't follow this.  We have out of process plug-ins on Windows right now.
>>   But the point is that the process that runs the plug-in is the same binary
>> that runs the browser itself, and if the latter becomes 64-bit then it can't
>> run 32-bit plug-ins.
>>
>> So what exactly is your "not too much code" proposal?
>>
>
> Why not just a ship a 32-bit browser along with the 64-bit browser on
> Windows, and run 32-bit plug-ins in a 32-bit browser, with ~ NPAPI IPC
> bridge.
>
> Ted tells me this is effectively what we are doing on OS X already.

My take on this, though I'm open to more data and more opinions, is that
we don't want to invest in 64-bit right now if that would require
solving the 32-bit plug-in issue. The people who could help there are
mostly or all busy with higher priority work.

- A

Benoit Jacob wrote:
> Ehsan tells me that I need to reduce the level of details in my email,
> so here goes the executive summary:
>
> The "we didn't measure a performance gain" approach to 64bit is
> misguided for 2 reasons:
>
> 1) 64bit is a much bigger win for emerging use cases such as gaming
> 2) the bigger gains require code changes which we have yet to do
> (SIMD) and likewise current performance problems can be easily fixed
> by code changes which we need to do.
>
> Benoit

Thanks, Benoit. This is much clearer for me.

You said in your earlier post,

> We can use SSE2 in 32bit code but we would have to compile also a
> non-SSE2 path, which would mean bigger, more complex code, and which
> means we can't just automatically benefit from it in the way we do
> in 64bit mode.

Is the "bigger, more complex code" just the output of the compiler -- a
bigger binary? If so, how much bigger and why not just go that rout so
that all of our 32-bit users (which outnumber our 64-bit users by quite
a bit) can get the benefits too? Or is that "bigger and more complex
code" going to have, because it's bigger and more complex, performance
costs that outweigh the performance wins?

Or more simply put, if we can get the wins with compiler adjustments for
all of our Windows users and not just 64-bit users, why wouldn't we just
do that?

Does that question even make sense?

- A

On Tuesday 2011-10-18 08:09 -0700, Asa Dotzler wrote:
> Jean-Marc Desperrier wrote:
> >Asa Dotzler a écrit :

> >>• With more registers, Firefox users on a 64-bit build could see fewer
> >>out of memory crashes
> >
> >More memory space actually.
>
> Thanks, Jean-Marc, for the correction here. There is general
> agreement, am I correct, that we should see fewer out of memory
> crashes with 64-bit builds? I just got the explanation wrong?

I think it depends how much memory the system has, since there are
two effects competing with each other:

 * some objects will use more memory on 64-bit builds (up to 2x, but
   since it's only some objects, the total increase should be much
   less than 2x).  (I would expect, for example, that JavaScript and
   DOM memory usage would increase a good bit though not the full
   2x; things like image data or graphical buffers shouldn't
   increase at all.)

 * 64-bit builds allow addressing more than 4GB of memory (since
   32-bit pointers only allow a range of 4GB)

In combination, I think this means that:

 * On systems with 4GB of memory + swap (total) or less, there would
   likely be slightly more out-of-memory crashes with a 64-bit
   build, since the objects are a little larger but the amount of
   addressable memory hasn't increased

 * On systems with greater than 4GB of memory + swap, there would be
   substantially fewer out-of-memory crashes with a 64-bit build,
   since the increase in the amount of addressable memory probably
   wins at only a little over 4GB.

I suspect that the machines running a 64-bit OS are, in general,
going to tend towards being the higher-memory machines, since one of
the reasons to run a 64-bit OS is to be able to address more than
4GB of memory.

-David

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

2011/10/18 Asa Dotzler <a...@mozilla.com>:

> Benoit Jacob wrote:
>>
>> Ehsan tells me that I need to reduce the level of details in my email,
>> so here goes the executive summary:
>>
>> The "we didn't measure a performance gain" approach to 64bit is
>> misguided for 2 reasons:
>>
>> 1) 64bit is a much bigger win for emerging use cases such as gaming
>> 2) the bigger gains require code changes which we have yet to do
>> (SIMD) and likewise current performance problems can be easily fixed
>> by code changes which we need to do.
>>
>> Benoit
>
> Thanks, Benoit. This is much clearer for me.
>
> You said in your earlier post,
>
>> We can use SSE2 in 32bit code but we would have to compile also a
>> non-SSE2 path, which would mean bigger, more complex code, and which
>> means we can't just automatically benefit from it in the way we do
>> in 64bit mode.
>
> Is the "bigger, more complex code" just the output of the compiler -- a
> bigger binary?

It's both a bigger binary, since the binary would have to contain SSE2
and x87 variants, and also bigger and more complex source code.

> If so, how much bigger and why not just go that rout so that
> all of our 32-bit users (which outnumber our 64-bit users by quite a bit)
> can get the benefits too? Or is that "bigger and more complex code" going to
> have, because it's bigger and more complex, performance costs that outweigh
> the performance wins?
>
> Or more simply put, if we can get the wins with compiler adjustments for all
> of our Windows users and not just 64-bit users, why wouldn't we just do
> that?

In the real world, we can't get in 32bit the same benefits as we get
automatically in 64bit, because that would be too much work.

In 32bit code, since we have to explicitly think and do work about
every place where we want to do SSE2, and since it's a
performance/size compromise, we end up not doing it in many places, so
we end up with x87 code in most places; while in 64bit code, the
compiler does it all for us for free. Again, here I'm not talking
about SIMD, which compilers are bad at doing automatically for us, I'm
talking about the part of SSE2 that replaces old x87 instructions.

Cheers,
Benoit

>
> Does that question even make sense?
>
> - A

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

2011/10/18 Asa Dotzler <a...@mozilla.com>:
> Benoit Jacob wrote:
>

>> While I understand that 64bit is not a clear improvement in many
>> general-purpose situations, 64bit can become a much bigger improvement
>> in situations where we do floating-point computations. Such situations
>> include:
>>   - WebGL
>>   - Canvas 2D
>>   - Layout (CSS etc)
>>   - Probably Audio/Video stuff though I'm not sure
>
> Thanks, Benoit. This is really helpful new information. Do you know if we
> have any tests that can demonstrate these gains on the current 64-bit builds
> when compared to the current 32-bit builds?

I admit I don't know a specific benchmark that you could run today in
Firefox to demonstrate this.

The best example will be when we get the ability use efficient
software rendering for WebGL. We want to get there, as it's the only
way to make WebGL available everywhere, and performance is critical as
only the fastest software renderers are fast enough to be useful. This
is exactly the kind of code that would benefit a lot from 64bit and
SSE2.

Benoit

On 10/18/11 10:55 AM, Benoit Jacob wrote:
> While I understand that 64bit is not a clear improvement in many
> general-purpose situations, 64bit can become a much bigger improvement
> in situations where we do floating-point computations. Such situations
> include:
>    - WebGL
>    - Canvas 2D
>    - Layout (CSS etc)

Most layout stuff is in fact done using integer computations, not
floating-point.  Of course we may change this some day, once ARM fp is
judged good enough and we work out some of the rounding-error kinks.

Also, the vast majority of layout time is typically not the computation
but the pointer-chasing, which is where cache pressure comes in....

Again, the upshot is that we need to measure to figure out what really
happens here with performance; just theorizing won't cut it.

-Boris

On 10/18/11 11:48 AM, Benoit Jacob wrote:
> The best example will be when we get the ability use efficient
> software rendering for WebGL. We want to get there, as it's the only
> way to make WebGL available everywhere, and performance is critical as
> only the fastest software renderers are fast enough to be useful. This
> is exactly the kind of code that would benefit a lot from 64bit and
> SSE2.

What's the ARM plan?  Or do we figure we'll be able to always do
hardware-accelerated GL on mobile?  If so, why won't we be able to do
that on desktop?

-Boris

On 10/18/11 11:07 AM, Benoit Jacob wrote:
> Ehsan tells me that I need to reduce the level of details in my email,
> so here goes the executive summary:
>
> The "we didn't measure a performance gain" approach to 64bit is
> misguided for 2 reasons:
>
> 1) 64bit is a much bigger win for emerging use cases such as gaming

Then we should measure those use cases and see how much of a win it is.
  No reason to restrict our measurements here to our basic tinderbox tests.

> 2) the bigger gains require code changes which we have yet to do
> (SIMD) and likewise current performance problems can be easily fixed
> by code changes which we need to do.

This is applicable to a fairly small portion of the codebase (primarily
the graphics and audio code, as far as I can tell).

With a very few exceptions, our performance bottlenecks are NOT in that
code right now.  That might change as use cases change, but we really
need to think about whole-system performance, not just computational
kernel performance.

-Boris

On 10/18/11 11:34 AM, L. David Baron wrote:
> In combination, I think this means that:
>
>   * On systems with 4GB of memory + swap (total) or less, there would
>     likely be slightly more out-of-memory crashes with a 64-bit
>     build, since the objects are a little larger but the amount of
>     addressable memory hasn't increased

That depends on how much of our address space usage is actually backed
by memory and how much is mmaped files and whatnot.  The latter are
actually a fairly large contribution to our overall address space usage
and getting more so as system libraries assume they have lots of address
space to work with and mmap all sorts of stuff (e.g. a bunch of font
files with DirectWrite unless you jump through hoops).

This is probably data worth gathering: what's our address space usage,
and what fraction of it is memory-backed?

-Boris

Jesse Ruderman schrieb:
> 2. With a larger virtual address space, users will see fewer
> out-of-memory crashes.

Do we have any knowledge or estimate on how many of the OOM crashes we
are seeing are cases where we run out of virtual memory as opposed to
hitting physical memory barriers of some sort (free RAM + potential swap
space or so)?
AFAIK, most of what we actually know on OOM crashes is that they exist
but not much more. We have a pretty stable and significantly high-ranked
number of crashes that come out as "empty signature" in crash-stats,
which are believed to be "mostly OOM issues" but as all their data
fields are empty, they don't really tell us a lot, so any grip we have
on some kind of data or estimate would be nice here.

Robert Kaiser

--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community should think about. And most of the
time, I even appreciate irony and fun! :)

On 10/18/11 10:46 AM, Wes Garland wrote:
> Why not just a ship a 32-bit browser along with the 64-bit browser on
> Windows

Asa's original cost covered that:

   This could also be mitigated by building a version that could
   fall-back to 32 bit plug-ins. That's a lot of work though and a
   resource conflict with E10S.

Or put another way, there is nothing "just" about this approach.  ;)

-Boris

Boris Zbarsky wrote:
> This is probably data worth gathering: what's our address space usage,
> and what fraction of it is memory-backed?
>
> -Boris

Boris, any suggestions on how we could collect this? Could telemetry
probes do this or do we need additional internals for those probes to
hook into? Or some completely other method?

- A

Benoit Jacob wrote:
> 2011/10/18 Asa Dotzler<a...@mozilla.com>:

>> You said in your earlier post,
>>
>>> We can use SSE2 in 32bit code but we would have to compile also a
>>> non-SSE2 path, which would mean bigger, more complex code, and which
>>> means we can't just automatically benefit from it in the way we do
>>> in 64bit mode.
>> Is the "bigger, more complex code" just the output of the compiler -- a
>> bigger binary?
>
> It's both a bigger binary, since the binary would have to contain SSE2
> and x87 variants, and also bigger and more complex source code.

OK. That's the part I wasn't clear on. So what I'm reading here is that
we'd have to write those alternate code paths for Firefox 32-bit but in
64-bit we'd get them mostly or completely for free. Is that correct?
Thanks for explaining all of this.

- A

On 10/18/11 1:29 PM, Asa Dotzler wrote:
> Boris, any suggestions on how we could collect this? Could telemetry
> probes do this or do we need additional internals for those probes to
> hook into? Or some completely other method?

I believe about:memory can already show this information, so hooking
into it with a telemetry probe should not be too bad.

-Boris

2011/10/18 Asa Dotzler <a...@mozilla.com>:
Yes, exactly. Again note that here I was excluding SIMD, as that part
requires more hand work.

2011/10/18 Boris Zbarsky <bzba...@mit.edu>:
Mobile is the place where all devices are GL ES 2.0 capable, and where
we have the highest probability of having a good, non-blacklisted GL
ES 2.0 driver. I am much more concerned about the desktop, where many
users have 10 year old machines with either insufficient hardware or
old drivers that will never get updated, and as a result we currently
support WebGL for only 40% of our users:

     http://people.mozilla.org/~bjacob/gfx_features_stats/

I'm not sure if we'd have any good ARM software rendering plan right
now. The first thing I'd check is if Mesa/llvmpipe supports ARM, as
that is a high performance open source renderer.

Benoit

>
> -Boris

On 10/18/2011 10:07 AM, Benoit Jacob wrote:
> 2) the bigger gains require code changes which we have yet to do
> (SIMD) and likewise current performance problems can be easily fixed
> by code changes which we need to do.

Is it possible to do a telemetry probe to see how many of our 32-bit
users would be up a creek if we made FF SSE2-only?

We ran these numbers before Firefox 4 and it was around 5% or so, IIRC.
Probably has declined a bit since then.

- Kyle

On Tue, Oct 18, 2011 at 8:34 AM, L. David Baron <dba...@dbaron.org> wrote:
>
>  * 64-bit builds allow addressing more than 4GB of memory (since
>   32-bit pointers only allow a range of 4GB)
>

> In combination, I think this means that:
>
>  * On systems with 4GB of memory + swap (total) or less, there would
>   likely be slightly more out-of-memory crashes with a 64-bit
>   build, since the objects are a little larger but the amount of
>   addressable memory hasn't increased
>

>  * On systems with greater than 4GB of memory + swap, there would be
>   substantially fewer out-of-memory crashes with a 64-bit build,
>   since the increase in the amount of addressable memory probably
>   wins at only a little over 4GB.

Aren't 32-bit builds typically limited to only 2GB, because the kernel
reserves 2GB for itself?  So if you have 4GB of RAM and a 32-bit
Firefox (a common configuration, I suspect) you will OOM when you've
used 2GB of address space even if you have physical RAM left.  A
64-bit build would avoid that problem.

Nick

No.  The LARGEADDRESSAWARE flag (which we set) allows the Win64 kernel to
move itself above the 4GB boundary and give the application the entire 4 GB
address space.

- Kyle

On 10/17/11 7:03 PM, Jesse Ruderman wrote:

> 2. With a larger virtual address space, users will see fewer
> out-of-memory crashes.
>

> ** This advantage is somewhat offset by the terrible swapping that can
> occur when you run out of physical RAM and need to continue GCing.

It would be interesting if we could tell the difference a
normal-but-loaded browser that OOMs after one wafer-thin malloc, vs one
that's OOMed by an enormous malloc / rapid DoS / leak. I suppose there's
a fuzzy area in the middle, with slow growth.

Justin

Nicholas Nethercote schrieb:

> Aren't 32-bit builds typically limited to only 2GB, because the kernel
> reserves 2GB for itself?

AFAIK, it's 1GB for the kernel, so 3GB overall or "for the rest" (of the
address space). On Linux, there have been some workaround applied to
address larger RAM amounts, but I seem to remember that for 32bit
Windows, it's always been 3GB RAM that has been the limit.

Robert Kaiser schrieb:

> Nicholas Nethercote schrieb:
>> Aren't 32-bit builds typically limited to only 2GB, because the kernel
>> reserves 2GB for itself?
>
> AFAIK, it's 1GB for the kernel, so 3GB overall or "for the rest" (of the
> address space). On Linux, there have been some workaround applied to
> address larger RAM amounts, but I seem to remember that for 32bit
> Windows, it's always been 3GB RAM that has been the limit.

(and of course that's for a 32bit OS - as Kyle has addressed (who knows
things like that far better than me), the application space on a 64bit
OS looks better even for a 32bit application (i.e. he says it can
address 4GB on its own).

(2011/10/19 0:11), Asa Dotzler wrote:
> Makoto Kato wrote:
>> Hi, Asa.
>>
>> Now, all automation tests are passed on Win64 build. Except to method
>> JIT, x64 will be faster than x86. Also, even if Linux x86-64 (current
>> tier-1), JIT is slower than x86.
>>
>> And, since accessibility DLL becomes 64-bit, any issue may occurs.
>
>
> Makoto, is your concern about the 64-bit accessibility DLL that we will
> break accessibility tools, or something else?

Although I am not accessibility guy, it may require accessibility
software of 64-bit version since IA2 DLL becomes 64-bit.


-- Makoto

On 10/17/2011 3:20 PM, Asa Dotzler wrote:
> Firefox 64-bit for Windows 7
>
> Disadvantages:*
> • Our 32-bit JITs are a bit better than the 64-bit ones. This could be
> mitigated by putting more effort into optimizing the 64-bit jits.

We can make the 64-bit jitcode equal to or better than the 32-bit
jitcode on Windows 7, if we are willing to limit JS to using < 2GB of
memory for objects, strings, and functions.

If we are unwilling to accept that limitation, it's less clear, we'll
probably still be pretty good on 64-bit with IonMonkey.

(Tech details) The reason is we can do equal or better with the
limitation is that we can constrain the JS heap to a contiguous space
within the low 32 bits of address space. That would allow us to generate
exactly the same code we do on 32-bit. We can then make it a bit better
by using the additional registers we get on 64-bit.

Dave

Kyle Huey a écrit :

>> >  Is it possible to do a telemetry probe to see how many of our 32-bit users
>> >  would be up a creek if we made FF SSE2-only?
>
> We ran these numbers before Firefox 4 and it was around 5% or so, IIRC.
> Probably has declined a bit since then.

https://bugzilla.mozilla.org/show_bug.cgi?id=593117
Extracted from crash data, could be done again quite easily.

Almost all of the non-SSE2 results were PII/non-SSE2 PIIIs and
Athlon/Athlon XP, 2/3 of the results being the first kind, and it was
almost 7% of the identifiable crashes.

However there's some good reasons to believe old, low memory machines
crash more, so that telemetry could give a more significant result.

David Mandelin a écrit :

> (Tech details) The reason is we can do equal or better with the
> limitation is that we can constrain the JS heap to a contiguous space
> within the low 32 bits of address space.

Getting seriously OT on planning, but would it be possible to do this
with a 2GB limit that applies separately for each compartment ? (1
compartment = 1 origin/webpage)
In which case, it would sound quite more acceptable.

That might work. There are a few issues, though: With generational GC,
you'd need one nursery per heap, which might add up to a lot. There
might be some workaround for that, though. Also, in the future, there
will most likely be one compartment per global, and one heap per global
might be costly. But we could still have one heap per origin in that setup.

Thanks everyone for the inputs. This week I'm going to be going back
through this thread, summarizing what's been shared here, and making a
recommendation from the Product team based on this data.

So, if you've been thinking about adding more here or otherwise
contributing to this discussion, please do so ASAP so that your inputs
can help inform our planning.

Thanks,
- A

Asa Dotzler wrote:
> Firefox 64-bit for Windows 7
>

> We've been making 64-bit builds of Firefox for Windows for some time now
> but they're not "official" so they don't receive the full development,
> testing, or release support that our 32-bit Windows build gets. They're
> "unofficial" as it were.
>
> Mozilla is evaluating the pros and cons of maintaining and shipping an
> official 64-bit version and so I'm reaching out to you all for further*
> input on the subject.
>
> Here's what I've gathered so far. If you can add to this or offer
> corrections, that'd be really helpful.
>
> Advantages:
> � With more registers, Firefox users on a 64-bit build could see fewer
> out of memory crashes (actually, out-of-virtual-address-space crashes.)
> This advantage could be somewhat mooted if we chase stability wins
> elsewhere.
> � Performance could be better. Compute-intensive things that fit
> entirely in cache might get faster. Performance could be improved with
> other efforts, though.
> � Better security. The address space layout can be randomized far more
> effectively when you have 2^64 address space to work with.
>
>
> Disadvantages:*
> � 64-bit Firefox will, in most cases, use more more memory than 32-bit
> Firefox. This could be mitigated by improved memory usage across all
> builds.
> � Our 32-bit JITs are a bit better than the 64-bit ones. This could be

> mitigated by putting more effort into optimizing the 64-bit jits.

> � User confusion about which Firefox build to use. This could be
> mitigated with a stub installer or defaulting to 32-bit unless users
> explicitly went seeking out 64-bit Firefox for Windows builds.
> � User confusion about what plug-ins and add-ons work with 64-bit
> Firefox. This might take shared work from Mozilla and plug-in vendors.
> � Maintaining another build/port means more build/test/qa infrastructure
> and effort. I'm not sure how this could be mitigated. We have already
> put some of the build and test infrastructure in place.
> � 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. This could be mitigated if
> Mozilla's official support for a 64-bit Firefox on Windows 7 encouraged
> plug-in vendors to increase their efforts around 64-bit. This could also

> be mitigated by building a version that could fall-back to 32 bit
> plug-ins. That's a lot of work though and a resource conflict with E10S.
>
>

> Additional info:
> � Flash, Java, and Silverlight all have 64-bit Windows NPAPI plug-ins,
> though at differing levels of completeness I believe.
> � About half of win7 users are on 64-bit versions. That may not sound
> like much, but it's about 2X our Mac and Linux users combined.
> � We don't have comparative performance data between 32-bit and 64-bit
> Firefox on the same hardware. I think we need that.
> � Competitively, IE9 doesn't ship an official 64-bit build and the
> unofficial one doesn't have a modern JS** implementation. Chrome also
> does not support 64-bit on Windows*** or Mac.
>
> So, the three potential wins are stability, performance, and security.
> The downsides are user confusion, memory usage, plug-in availability,
> and resource costs.
>
> Does this paint a fair picture? What am I wrong about or missing?
>
> - A
>
>
> *
> http://weblogs.mozillazine.org/asa/archives/2011/07/questions_about_64bi.html
>
> ** http://zd.net/p7hObC
> *** http://code.google.com/p/chromium/issues/detail?id=8606