Closed Bug 836658 Opened 7 years ago Closed 5 years ago

VC11+ defaults to SSE2 builds by default

Categories

(Firefox Build System :: General, defect, blocker)

x86
Windows 7
defect
Not set
blocker

Tracking

(Not tracked)

RESOLVED FIXED
mozilla33

People

(Reporter: yuhongbao_386, Assigned: dmajor)

References

Details

Attachments

(3 files)

VC11 defaults to SSE2 builds by default, which will crash on pre-SSE2 hardware. Disable using /arch:ia32.
Blocks: VC11
Severity: normal → major
Severity: major → blocker
For performance reasons, would it not be sensible to start requiring SSE2 capable hardware?
(In reply to Nick Lowe from comment #1)
> For performance reasons, would it not be sensible to start requiring SSE2
> capable hardware?

Because we have millions of users still not using hardware with SSE2. We don't want to upset those users.
Matt: is this something you have noticed?
Flags: needinfo?(mbrubeck)
(In reply to Gregory Szorc [:gps] from comment #3)
> Matt: is this something you have noticed?

No.  Since our Metro build no longer requires MSVC11, many of the developers and all of the buildbot slaves have gone back to MSVC10.  There are a some of us still using VC11, but probably none us are running on non-SSE2 hardware.
Flags: needinfo?(mbrubeck)
I can confirm that VC11 defaults to /arch:SSE2 (x86 compiler)
If you want to build for non-SSE2 hardware it needs /arch:IA32 as a switch which will disable SSE2 compilations.

Ref: http://msdn.microsoft.com/en-us/library/vstudio/7t5yh4fd.aspx
(In reply to Gregory Szorc [:gps] from comment #2)
> (In reply to Nick Lowe from comment #1)
> > For performance reasons, would it not be sensible to start requiring SSE2
> > capable hardware?
> 
> Because we have millions of users still not using hardware with SSE2.

How do we know that?  It does not look like the health report contains that information.
(In reply to Lars T Hansen [:lth] from comment #6)
> How do we know that?  It does not look like the health report contains that
> information.

We have /some/ information in the crash database. (specifically, family, model and stepping for cpus of users reporting crashes)
Duplicate of this bug: 997401
Blocks: VC12
Summary: VC11 defaults to SSE2 builds by default → VC11+ defaults to SSE2 builds by default
(In reply to Gregory Szorc [:gps] from comment #2)
> (In reply to Nick Lowe from comment #1)
> > For performance reasons, would it not be sensible to start requiring SSE2
> > capable hardware?
> 
> Because we have millions of users still not using hardware with SSE2. We
> don't want to upset those users.

The system-requirement-page states that SSE2-hardware is required by now:
http://www.mozilla.org/en-US/firefox/29.0/system-requirements/
It's the recommended hardware, not the requirement.
What are the statistics now for machines that lack SSE2?

Do machines that lack the instructions even have the processing power or RAM to work properly with the modern Web?
IIRC the stats from the corresponding dev-platform thread, there are more users with non-SSE2 Windows than there are Linux users.
For the record, Chrome's justification for now requiring SSE2 was according to Carlos Pizano:

"The decision was made because

1- Allowing the compiler to use SSE2 instructions results in a faster Chrome for the 99.8% of the population. Note that the compiler uses them not just in floating point instructions but in any place it can.

2- The toolchain (VS2013) default mode is SSE2, which means is the mode that is better tested. Every codegen bug we tickle in the toolchain is a nightmare to diagnose / workaround. Every time we upgrade toolchains we have to fight (in average) 4 of these.

3- We need to support AVX for media, so the potential number of codepaths we need to keep working is getting out of hand. Removing the pre-SSE2 code means less bugs in the future.

4- The minimum requirements already stated P4 (or equivalent) for more than a year. We were not enforcing them. Also the PIII population has gone down dramatically in the last 2 years.

Note that most non SSE2 (PIII) machines can't run anything but XP. Machines like [the] Athlon are very rare."

"Now, it might not be a 'small' number, but nothing at Google scale is. So we optimize for most users and like I said before in this case overwhelmingly so."
(In reply to Nick Lowe from comment #14)
> Note that most non SSE2 (PIII) machines can't run anything but XP. Machines
> like [the] Athlon are very rare."

Not entirely correct - many, many Athlon-XP machines have been sold and are still in use. Athlon-XP is more modern than the P4 (latest new release in 2004 of the processor), but has been lagging behind in SSE2 support (since they had their own AMD instruction set instead of Intel's, 3DNow, which even has SSE3-like capabilities in some areas).

I'm not sure how many people are still using Athlon XPs in 2014, but calling it "very rare" is a bit of a misconception, IMHO.
Goog(In reply to Mark Straver from comment #15)
> (In reply to Nick Lowe from comment #14)
> > Note that most non SSE2 (PIII) machines can't run anything but XP. Machines
> > like [the] Athlon are very rare."
> 
> Not entirely correct - many, many Athlon-XP machines have been sold and are
> still in use. Athlon-XP is more modern than the P4 (latest new release in
> 2004 of the processor), but has been lagging behind in SSE2 support (since
> they had their own AMD instruction set instead of Intel's, 3DNow, which even
> has SSE3-like capabilities in some areas).
> 
> I'm not sure how many people are still using Athlon XPs in 2014, but calling
> it "very rare" is a bit of a misconception, IMHO.

Google's stats were that at the point they made the change to SSE2 only, ~0.2% of their users were on a system without it. I think that's what me means by rare. This percentage may well be higher for Firefox users of course.
*that's what he means
(In reply to Nick Lowe from comment #16)
> Google's stats were that at the point they made the change to SSE2 only,
> ~0.2% of their users were on a system without it.

How, exactly, did Google measure this? 

Telemetrics in Chrome?
I don't think Chrome ever ran particularly well on old hardware so those figures could well be skewed; I don't think any of the people I know on those processors were ever happy about how it performed so likely never used it or only briefly did.

Some other way?
I'd like to know how they got to those figures then.

From a user perspective: If Chrome no longer supports their processor, Firefox is likely the only mainstream modern browser they can still use (especially since IE is linked to OS, and those people are likely not running Win 8). If Firefox no longer supports them as well, where are they going to go for their browser needs?
(In reply to Mark Straver from comment #18)
> From a user perspective: If Chrome no longer supports their processor,
> Firefox is likely the only mainstream modern browser they can still use
> (especially since IE is linked to OS, and those people are likely not
> running Win 8). If Firefox no longer supports them as well, where are they
> going to go for their browser needs?

To a third party maintained build... Yes it would not be mainstream, but how would that be any different to TenFourFox supplying builds for OS X 10.4 and OS X 10.5 which Mozilla no longer supports?

Firefox also no longer supports Windows 2000 or Windows XP RTM/SP1. Remember that users will often only change hardware as a result of changes in software requirements and will otherwise hang on with what they have. Waiting for attrition alone just does not work in a reasonable time frame.

Remember these users are likely running an operating system (Windows XP SP3) that is no longer maintained for security fixes.
(In reply to Mark Straver from comment #18)
> From a user perspective: If Chrome no longer supports their processor,
> Firefox is likely the only mainstream modern browser they can still use
> (especially since IE is linked to OS, and those people are likely not
> running Win 8).

Not only not likely, but not at all. Win8 requires SSE2.
(In reply to Elbart from comment #20)
> (In reply to Mark Straver from comment #18)
> > From a user perspective: If Chrome no longer supports their processor,
> > Firefox is likely the only mainstream modern browser they can still use
> > (especially since IE is linked to OS, and those people are likely not
> > running Win 8).
> 
> Not only not likely, but not at all. Win8 requires SSE2.

Windows 7 can run Internet Explorer 11.
I think this discussion should be taken to a mailing list such as dev-platform.
I'm going to prepare a patch to use /arch:IA32. This is not intended to belittle the discussion or preclude the possibility of using SSE2 in the future. For the time being, our upgrade to VS2013 should not be blocked on or mixed up with any decisions about SSE2.
Assignee: nobody → dmajor
Attachment #8454247 - Flags: review?(mh+mozilla)
Attachment #8454248 - Flags: review?(wtc)
Attachment #8454249 - Flags: review?(wtc)
I have a worry about hard-coding these flags this way: can they still be overridden with --enable-optimize="-arch:SSE2" and similar flags for all affected code?

I'd suggest making this part of release engineering (default .mozconfig, etc) instead of hard-coding it in the tree.

As a side note: In addition, selecting IA32 in later versions of VS is using a deprecated optimization method that is only supplied by Microsoft for continued backwards compatibility. Not surprising, since VS2013 focuses on Windows 8 primarily that requires SSE2 as well. I don't expect these compiler routines to receive the same amount of attention the default ones (SSE2) get.
Forcing this like David has done is the right approach.  It's OK for people to be able to override this with various methods such as --enable-optimize, that is not what we are trying to protect against here.
My question was if it impacts being able to still use --enable-optimize or if it will still negatively impact builds that currently use SSE2 everywhere (by default). Is the -arch:IA32 always overrideable with --enable-optimize with the current build system?
Comment on attachment 8454248 [details] [diff] [review]
-arch:IA32 for NSS

r=wtc.

I verified /arch:IA32 was added in Visual Studio 2012 and it is
equivalent to the behavior of Visual Studio 2010 if /arch is not
used.

I added a sentence from David's commit message to the comment
and checked this in:
https://hg.mozilla.org/projects/nss/rev/65605e800fd1
Attachment #8454248 - Flags: review?(wtc)
Attachment #8454248 - Flags: review+
Attachment #8454248 - Flags: checkin+
Comment on attachment 8454249 [details] [diff] [review]
-arch:IA32 for NSPR

r=wtc.

Edited the comment and checked the patch in:
https://hg.mozilla.org/projects/nspr/rev/b071bf728a8b
Attachment #8454249 - Flags: review?(wtc)
Attachment #8454249 - Flags: review+
Attachment #8454249 - Flags: checkin+
(In reply to comment #29)
> My question was if it impacts being able to still use --enable-optimize or if
> it will still negatively impact builds that currently use SSE2 everywhere (by
> default). Is the -arch:IA32 always overrideable with --enable-optimize with the
> current build system?

I think for local builds you can just export CFLAGS and CXXFLAGS in your mozconfig to set them to whatever you want, and those should override whatever values the build system uses by default.  If that doesn't work, please file a bug, that would be a different issue.
Comment on attachment 8454247 [details] [diff] [review]
-arch:IA32 for top-level configure and JS configure

Review of attachment 8454247 [details] [diff] [review]:
-----------------------------------------------------------------

::: js/src/configure.in
@@ +1651,5 @@
>          CXXFLAGS="$CXXFLAGS -W3 -Gy"
> +        if test "$_CC_SUITE" -ge "11"; then
> +            dnl VS2012+ defaults to -arch:SSE2.
> +            CFLAGS="$CFLAGS -arch:IA32"
> +            CXXFLAGS="$CXXFLAGS -arch:IA32"

Is that enough for PGO, or is a linker flag required there too (considering in PGO builds, it's the linker that's actually producing code, but maybe the compiler adds linker instructions about that?)
Attachment #8454247 - Flags: review?(mh+mozilla) → review+
(In reply to Mike Hommey [:glandium] from comment #33)
> Is that enough for PGO, or is a linker flag required there too (considering
> in PGO builds, it's the linker that's actually producing code, but maybe the
> compiler adds linker instructions about that?)

It had better be doing that, since the value of -arch is available during preprocessing as _M_IX86_FP. I don't see any separate linker switches for it.

(In reply to Mark Straver from comment #29)
> Is the -arch:IA32 always overrideable with --enable-optimize
> with the current build system?

Yes.
https://hg.mozilla.org/mozilla-central/rev/0ddd5a0fac8a
Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla33
-arch:IA32 is not valid when doing x64 builds, but configure will now unconditionally add it.  This creates a lot of spam during the build:

cl : Command line warning D9002 : ignoring unknown option '-arch:IA32'

We should only add this option when doing 32-bit builds.
Depends on: 1043108
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.