Yuhong Bao Reporter
	Description • 12 years ago

VC11 defaults to SSE2 builds by default, which will crash on pre-SSE2 hardware. Disable using /arch:ia32.

	Nick Lowe
	Comment 1 • 12 years ago

For performance reasons, would it not be sensible to start requiring SSE2 capable hardware?

	Gregory Szorc [:gps]
	Comment 2 • 12 years ago

(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.

	Gregory Szorc [:gps]
	Comment 3 • 12 years ago

Matt: is this something you have noticed?

	Matt Brubeck (:mbrubeck)
	Comment 4 • 12 years ago

(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.

	Mark Straver
	Comment 5 • 11 years ago

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

	Lars T Hansen [:lth]
	Comment 6 • 10 years ago

(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.

	Mike Hommey [:glandium]
	Comment 7 • 10 years ago

(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)

	Elbart
	Comment 9 • 10 years ago

(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/

	Masatoshi Kimura [:emk]
	Comment 10 • 10 years ago

It's the recommended hardware, not the requirement.

	Nick Lowe
	Comment 11 • 10 years ago

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?

	Mike Hommey [:glandium]
	Comment 12 • 10 years ago

IIRC the stats from the corresponding dev-platform thread, there are more users with non-SSE2 Windows than there are Linux users.

	Nick Lowe
	Comment 13 • 10 years ago

Chrome went to a SSE2 only build from version 35 onwards:

http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/startup/obsolete_system_infobar_delegate.cc?r1=256498&r2=256497&pathrev=256498

https://support.google.com/chrome/answer/95411

	Nick Lowe
	Comment 14 • 10 years ago

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."

	Mark Straver
	Comment 15 • 10 years ago

(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.

	Nick Lowe
	Comment 16 • 10 years ago

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.

	Nick Lowe
	Comment 17 • 10 years ago

*that's what he means

	Mark Straver
	Comment 18 • 10 years ago

(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?

	Nick Lowe
	Comment 19 • 10 years ago

(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.

	Elbart
	Comment 20 • 10 years ago

(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.

	Nick Lowe
	Comment 21 • 10 years ago

(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.

	Gregory Szorc [:gps]
	Comment 22 • 10 years ago

I think this discussion should be taken to a mailing list such as dev-platform.

	(Away) Assignee
	Comment 23 • 10 years ago

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.

	Mark Straver
	Comment 27 • 10 years ago

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.

	(no longer active)
	Comment 28 • 10 years ago

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.

	Mark Straver
	Comment 29 • 10 years ago

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?

	Wan-Teh Chang
	Comment 30 • 10 years ago

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

	Wan-Teh Chang
	Comment 31 • 10 years ago

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

	(no longer active)
	Comment 32 • 10 years ago

(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.

	Mike Hommey [:glandium]
	Comment 33 • 10 years ago

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?)

	(Away) Assignee
	Comment 34 • 10 years ago

(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.

	(Away) Assignee
	Comment 35 • 10 years ago

https://hg.mozilla.org/integration/mozilla-inbound/rev/0ddd5a0fac8a

	Carsten Book [:Tomcat]
	Comment 36 • 10 years ago

https://hg.mozilla.org/mozilla-central/rev/0ddd5a0fac8a

	Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)
	Comment 37 • 10 years ago

-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.