Requiring SSE2 on all 32-bit x86 OSs (was: Re: Reverting to VS2013 on central and aurora)

[Henri Sivonen]

On Mon, May 16, 2016 at 8:53 PM, Benjamin Smedberg
<benj...@smedbergs.us> wrote:
> On Mon, May 16, 2016 at 8:47 AM, Henri Sivonen <hsiv...@hsivonen.fi> wrote:
>> For clarification: Does this decision apply to 32-bit x86 Linux as
>> well? (It would be sad to have to supply and maintain non-SSE2 x86
>> code paths just for Linux.)
>
> Nobody asked about that, so it's wasn't specifically included.
...
> so the real question here is whether we want
> to support distros that don't require SSE2?

So we now require SSE2 on
* All x86_64 (since SSE2 is part of the x86_64 baseline)
* 32-bit x86 Mac, which means just the plugin-container now that we
no longer support 10.6, which was the last OS X version that ran on
32-bit hardware.
* 32-bit x86 Windows.

It seems that we are almost ready to require SSE2 for Mozilla-built
Firefox for 32-bit x86 Linux.

What do we need to do to reach a decision on that?

That leaves Linux distro-shipped Firefox and *BSD ports.

The combination of the lack of function-level instruction set options
in LLVM and the inconvenience of per-function compilation units in
Rust probably would naturally make *run-time* selection of SSE2 vs.
non-SSE2 a "patches not even welcome" kind of thing. (At least until
LLVM and then rustc get per-function instruction set options.)

What do we need to do to reach a decision that it's indeed OK to treat
*run-time* selection of SSE2 vs. non-SSE2 especially in Rust code as a
"patches not even welcome" kind of thing, considering that this may
lead to Linux distros shipping an 32-bit x86 "Firefox" with degraded
performance relative to Mozilla-shipped 32-bit x86 Firefox?

On Mon, May 16, 2016 at 9:14 PM, Ralph Giles <gi...@mozilla.com> wrote:
> It's also not clear how many of the distros which technically target
> i[345]86 actually function on non-SSE2 hardware. It's easy for
> non-compliant binaries to slip in if there's no active testing for
> this.

Should we prepare a list of distros that already documentedly require
SSE2 and then test the other ones on non-SSE2 hardware to see if they
already de facto require SSE2, too? Who would do the testing?

Does there exist computers whose GPU has OpenGL driver support in
Ubuntu and Fedora but whose CPU doesn't have SSE2? Because if the GPU
doesn't have OpenGL driver support, the llvmpipe seems to bring a SSE2
requirement. (Maybe such computers run LXDE instead of an
OpenGL-composited environment anyway.)

--
Henri Sivonen
hsiv...@hsivonen.fi
https://hsivonen.fi/

[Mike Hommey]

This paragraph doesn't make sense to me. That is, I don't see the
relationship between "patches not even welcome" and degraded performance
relative to Mozilla-shipped 32-bit x86 Firefox.

Also note that in practice, there *already* is a performance difference
between Mozilla-shipped Firefox and distro-shipped Firefox: most
distros-shipped packages don't build with PGO. That might even count for
more performance differences than building with/without SSE2 would make.
(That would actually be an interesting thing to check with Talos)

Now, with my Debian hat on, I can tell you with 100% certainty that
angry Debian users *will* come with patches and will return even
angrier if patches are not even welcome.

That said, Talos could tell something different, but I'm not convinced
building with SSE2 would make a huge difference. Things where it does
make huge differences are already using run-time selected SSE2 code.
And even if it does make huge differences, I'm tempted to say "so what"?
So, if people want to build the same way as currently, even if Mozilla
and most distros end up defaulting to SSE2, why prevent them from doing
so? Why specifically not welcome patches, instead of, say, making it
tier-3, like e.g. sparc or mips?

Mike

[Tobias B. Besemer]

N00b question:
Is this really a discussion if Firefox should support CPUs older then 13-15 years ???

https://en.wikipedia.org/wiki/SSE2

I can't imagine any scenario were a user needs to run a Pentium III with GUI and a browser on it...
...would mean that the system not only runs not e.g. as a proxy where the user have no normal desktop and a browser on it...
...would also mean that the user can't exchange the hardware e.g. by a ~150 dollar new Mini-PC...
...and that the user have to run all together with a system with 512MB-1.5GB mem...

https://answers.yahoo.com/question/index?qid=20071212213049AAd5SbG

[Tobias B. Besemer]

...would also mean that the user can't stay in future on FF46 because:
a.) He needs the newest web-technologies not yet implemented in FF46.
b.) He browse not only on his own HD, a Intranet, or save pages and so he needs to keep his FF up-to-date against the newest found security holes.

[Tobias B. Besemer]

Motherboards to this CPUs normally should only support IDE HDs...
I had a quick look in my storage and the biggest IDE HD I found was a WD with 80GB and a production date of 2003-03-12...
...maybe I had a 150GB HD in the past too, but my first SATA had 250GB...
...don't know if the IDE would still run...
...and when, how long... :D

[Boris Zbarsky]

On 5/18/16 7:38 AM, Tobias B. Besemer wrote:
> Is this really a discussion if Firefox should support CPUs older then 13-15 years ???

More or less, yes.

> I can't imagine any scenario were a user needs to run a Pentium III with GUI and a browser on it...

There were AMD CPUs newer than that without SSE2.

But more importantly, we have concrete evidence, via crash-stats, that
such users exist, in small amounts. So the theoretical "I can't imagine
why anyone would do it" argument runs into the experimental "these
people clearly exist" issue.

-Boris

[Mike Hoye]

On 2016-05-18 7:38 AM, Tobias B. Besemer wrote:
> N00b question:
> Is this really a discussion if Firefox should support CPUs older then 13-15 years ??

Right now Firefox supports users on platforms their creators have long
abandoned - WinXP, pre-SSE2 CPUs, OSX 10.6-8, older Android. Firefox is
the _only_ choice people on those platforms have for a safe, modern web
browser, and ending support for them will have real consequences for
real people.

We can't support everyone on every platform forever, obviously, and
being the dominant browser on a set of obsolete or dying platforms isn't
a compelling long-term investment of our resources. But it's a good bet
that people using those systems can't easily upgrade, so ending support
for a platform inevitably means exposing those users to unknown risks.
So it's not a decision people who care about their users' safety and
security should make casually, without careful deliberation and the best
data available.

So to answer your question: Yeah, sort of. This is kind of a discussion
about whether Firefox should support 15-year-old CPUs, but it's really
about the costs, benefits and trade-offs involved in deploying scarce
engineering resources in a complex environment, and how to best support
our users and advance Mozilla's mission in that context.

For what it's worth I think our users deserve to know we take these
questions seriously, whatever the final decisions, and I'm glad we do.

- mhoye

[Tobias B. Besemer]

I wrote 13-15 years, because Intel did it 15 years ago and AMD 13 years ago.

Crash-stats with FF >40?

There was ~1 year ago a request at Avira to support non-SSE2 again with there scanner again...
AFAIKR I wrote to it, that the user should have a look into BIOS if there is a SSE2 support that can be turned on, because I can imagine that this was a long time optional and e.g. after a BIOS-Reset it was turned off... Think there came never any answer back in the Feedback-Community...

Is it possible in the stats to see, if the systems _should_ support it?
(E.g. what kind of CPU is used by the system...)

[Jim Blandy]

I think we need to admit that there isn't any rational, analytical way to
compare most of the costs here. The one number we *do* have, the number of
users who can't upgrade, is kind of tantalizing us, but we can't quantify
how many users we'll gain by requiring SSE2, how many other bugs we'll fix
because engineers don't need to worry about old CPUs, and so on.

When you can't be rational, often the next best thing is to be fair. For
example, our choice to support ESRs for a year is a similar arbitrary
choice: we don't re-evaluate who will be affected each time an ESR is about
to expire. We just announce a policy in advance that is useful to a large
number of people, and then follow it.

One analogous approach here would be to simply decide not to support CPUs
sold new more than N years ago.

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

[Benjamin Smedberg]

On Wed, May 18, 2016 at 6:54 AM, Mike Hommey <m...@glandium.org> wrote:

> Henri Sivonen wrote:
>
> > It seems that we are almost ready to require SSE2 for Mozilla-built
> > Firefox for 32-bit x86 Linux.
>

There are a couple of interrelated issues here.

Can we require SSE2 for Mozilla builds of Firefox for Linux? Yes, I am
comfortable making that decision today.

Should we also take actions that prevent anyone from supporting non-SSE2
codepaths? I don't know. There seem to be at least a few cases that this
affects:

- Rust and its support for non-SSE2 arches
- This seems to be both about build-time targeting and runtime
dynamic selection. I don't personally understand the
cost/benefit tradeoff
here.
- Our own JITs and their support for non-SSE2 paths
- Our primary JIT doesn't support non-SSE2, right? So these users
already fall back to the slow interpretation path?
- Other platform code that does dynamic SSE2 detection. For example,
image decoders which we compiler in both SSE2 and non-SSE2 configs
currently, and select the codepath at runtime.
- I imagine we'd like to remove this complexity from the tree,
especially given that we won't have any testing for it.
- Our relationships with 3rd-party code, in particular Flash,
OpenH264, Widevine, and Primetime
- Some of these already don't support non-SSE2 and may not ever.

> Now, with my Debian hat on, I can tell you with 100% certainty that
> angry Debian users *will* come with patches and will return even
> angrier if patches are not even welcome.
>

In the abstract, I'm willing to accept the cost of a minority of angry
users for an offsetting benefit; that benefit can either be perf
improvements or maintenance/development improvements in the Firefox
codebase. I just don't understand the costs yet.

> That said, Talos could tell something different, but I'm not convinced
> building with SSE2 would make a huge difference. Things where it does
> make huge differences are already using run-time selected SSE2 code.
> And even if it does make huge differences, I'm tempted to say "so what"?
> So, if people want to build the same way as currently, even if Mozilla
> and most distros end up defaulting to SSE2, why prevent them from doing
> so? Why specifically not welcome patches, instead of, say, making it
> tier-3, like e.g. sparc or mips?
>

One obvious cost is either continued testing of the runtime selection
codepaths, *or* releasing code which we haven't tested. And the mental
overhead of changing that code. Although I bet we aren't testing the
non-SSE2 codepaths even right now, given how hard it has been to find any
machine at Mozilla that didn't have SSE2.

If we're going to accidentally keep introducing bugs where non-SSE2 CPUs
crash, it would be far better to add a runtime check at the beginning of
main() and error out, than to have a steady trickle of bug reports about
crashes on illegal instructions which end up being marked INVALID.

--BDS

[Ralph Giles]

On Wed, May 18, 2016 at 11:10:30AM +0300, Henri Sivonen wrote:

>> So we now require SSE2 on [...]

>> * 32-bit x86 Mac, which means just the plugin-container now that we
>> no longer support 10.6, which was the last OS X version that ran on
>> 32-bit hardware.

Actually, all of Apple's intel hardware supports SSE2, regardless of
64-bit support.

On Wed, May 18, 2016 at 3:54 AM, Mike Hommey <m...@glandium.org> wrote:

> Now, with my Debian hat on, I can tell you with 100% certainty that
> angry Debian users *will* come with patches and will return even
> angrier if patches are not even welcome.

There are two parts here. I believe Henri was describing patches for
run-time selection of non-SSE2 code in rust not being welcome. That's
separate from being able to build with compile-time selection, through
code generation options and conditional inline assembly.

-r

[Tobias B. Besemer]

> If we're going to accidentally keep introducing bugs where non-SSE2 CPUs
> crash, it would be far better to add a runtime check at the beginning of
> main() and error out, than to have a steady trickle of bug reports about
> crashes on illegal instructions which end up being marked INVALID.

Think, if it would be possible that FF brings at the start a error msg that non-SSE2 is no more supported if there is no support recognized, that would be IMHO great!

Else, I guess that Mozilla can carefully stop support non-SSE2 systems and cloth at the beginning warm because of all the negative feedback that will come to it... ;-)

[Jim Blandy]

On Wed, May 18, 2016 at 9:51 AM, Ralph Giles <gi...@mozilla.com> wrote:

> On Wed, May 18, 2016 at 3:54 AM, Mike Hommey <m...@glandium.org> wrote:
>
> > Now, with my Debian hat on, I can tell you with 100% certainty that
> > angry Debian users *will* come with patches and will return even
> > angrier if patches are not even welcome.
>

Since this paragraph is getting quoted a lot: I *believe* Mike's point was
only that this could be counted on to occur --- not that it should
influence the decision much. At Mozilla's scale, obviously, tiny minorities
of our users can still be thousands strong.

[Markus Stange]

On 2016-05-18 1:32 PM, Benjamin Smedberg wrote:
> - Other platform code that does dynamic SSE2 detection. For example,
> image decoders which we compiler in both SSE2 and non-SSE2 configs
> currently, and select the codepath at runtime.
> - I imagine we'd like to remove this complexity from the tree,
> especially given that we won't have any testing for it.

Wouldn't these code paths still be tested on Android? I expect we have
many code paths that have an SSE2 specialization but not an ARM NEON
one, so we use the non-SSE2 code paths on ARM.
The Moz2D software filter code is an example of such a case.

-Markus

[Tobias B. Besemer]

Idea: Try to implement a check and error msg already in FF47 and look if someone starts to scream. If yes, a FF47.0.1 can be easily shipped with the check and error msg removed again. If no, the devs can start to remove the old code step-by-step.

[Emanuel Hoogeveen]

On Wednesday, May 18, 2016 at 7:32:38 PM UTC+2, Benjamin Smedberg wrote:
> - Our own JITs and their support for non-SSE2 paths
> - Our primary JIT doesn't support non-SSE2, right? So these users
> already fall back to the slow interpretation path?

They do get the baseline compiler, which can still be significantly faster than the interpreter, but Ion requires SSE2. Since the runtime detection does just turn Ion off altogether, I don't know if we would gain much by removing it (the ability to disable Ion isn't going away).

IIRC our fuzzers already compile with SSE2 enabled to avoid hitting floating point differences during differential testing (testing the interpreter against baseline, against Ion). Enabling SSE2 for all builds would remove those differences, which might be beneficial in its own right (since content JS running in Ion would no longer behave differently than in baseline or the interpreter).

[Jan de Mooij]

On Thu, May 19, 2016 at 2:59 AM, Emanuel Hoogeveen
<emanuel....@gmail.com> wrote:
>
> They do get the baseline compiler, which can still be significantly faster than the interpreter, but Ion requires SSE2. Since the runtime detection does just turn Ion off altogether, I don't know if we would gain much by removing it (the ability to disable Ion isn't going away).
>

We will have to make a similar decision for WebAssembly. Odin (our
Ion-based asm.js compiler) requires SSE2, but there we can at least
use the much slower 'normal JS' path. For WebAssembly, we have the
following options IIUC:

(1) Don't support wasm on those ancient CPUs. This may work for a
while, but at some point we may include wasm modules in Firefox and
add-ons, normal websites will start to use it, etc.
(2) Add x87 floating-point support to the wasm baseline JIT - very
complicated and likely not worth it.
(3) Call into C++ for all floating point and SIMD operations. This
will be horribly slow.
(4) Add a wasm interpreter. Again, likely not worth the effort if it's
just for this.

Jan

[Jan de Mooij]

On Thu, May 19, 2016 at 2:59 AM, Emanuel Hoogeveen <
emanuel....@gmail.com> wrote:

> They do get the baseline compiler, which can still be significantly faster
> than the interpreter, but Ion requires SSE2. Since the runtime detection
> does just turn Ion off altogether, I don't know if we would gain much by
> removing it (the ability to disable Ion isn't going away).
>

We will have to make a similar decision for WebAssembly. Odin (our
Ion-based asm.js compiler) requires SSE2, but there we can at least use the
much slower 'normal JS' path. For WebAssembly, we have the following
options IIUC:

(1) Don't support wasm on those ancient CPUs. This may work for a while,

but at some point we may include wasm modules in Firefox, normal websites

will start to use it, etc.

(2) Add x87 floating-point support to the wasm baseline JIT - very
complicated and likely not worth it.

(3) Call into C++ for all floating point and SIMD operations. This will be
horribly slow.

(4) Add a wasm interpreter. Again, likely not worth the effort if it's just
for this.

Jan

> IIRC our fuzzers already compile with SSE2 enabled to avoid hitting
> floating point differences during differential testing (testing the
> interpreter against baseline, against Ion). Enabling SSE2 for all builds
> would remove those differences, which might be beneficial in its own right
> (since content JS running in Ion would no longer behave differently than in
> baseline or the interpreter).

[Henri Sivonen]

On Wed, May 18, 2016 at 8:32 PM, Benjamin Smedberg
<benj...@smedbergs.us> wrote:
> Can we require SSE2 for Mozilla builds of Firefox for Linux? Yes, I am
> comfortable making that decision today.

Thank you! I filed
https://bugzilla.mozilla.org/show_bug.cgi?id=1274196 for this.

> Should we also take actions that prevent anyone from supporting non-SSE2
> codepaths? I don't know. There seem to be at least a few cases that this
> affects:
>

> Rust and its support for non-SSE2 arches
>

> This seems to be both about build-time targeting and runtime dynamic
> selection. I don't personally understand the cost/benefit tradeoff here.

There are two levels of complication with run-time selection:

1) Since inline asm isn't allowed in stable-channel Rust, executing
the cpuid instruction must be done in some other way, which leads
either to having to make the crate (that could otherwise be a
standalone Rust library) depend on Gecko's existing CPU sniffing
infrastructure or to having to link some ad hoc cpuid-execution
non-Rust object to the crate that could otherwise be a simple
pure-Rust crate.

2) Since LLVM and, by extension, rustc currently require the compiler
instruction set targeting options to be the same throughout the
compilation unit, if the main crate is compiled without SSE2 to cater
for the non-SSE2 case, the SSE2-enabled versions of functions need to
be put in a separate crate, which is considerably less nice than what
rustc lets you do if you want to supply SSE2 and ALU-only alternatives
for a function such that the selection is done at compile time. In
particular, if you want to avoid having two copies of SSE2 code, one
in the main crate for build-time selection and the other in the
SSE2-only helper crate, you have to put the single copy in the helper
crate, which means that the preferred case (SSE2 enabled at build
time) is made more complex, too.

The problem with build-time selection is that the non-SSE2 target
isn't the target that the Rust community tests the most actively.
(Just like, evidently, Microsoft doesn't actively test the non-SSE
target of MSVC.)

> I imagine we'd like to remove this complexity from the tree, especially
> given that we won't have any testing for it.

I agree, though with C++, the complexity of having one function in a
different compilation unit is more on the level of the general
complexity of C++ whereas with Rust, the difference is more
distinctive.

On Wed, May 18, 2016 at 1:54 PM, Mike Hommey <m...@glandium.org> wrote:
>> What do we need to do to reach a decision that it's indeed OK to treat
>> *run-time* selection of SSE2 vs. non-SSE2 especially in Rust code as a
>> "patches not even welcome" kind of thing, considering that this may
>> lead to Linux distros shipping an 32-bit x86 "Firefox" with degraded
>> performance relative to Mozilla-shipped 32-bit x86 Firefox?
>
> This paragraph doesn't make sense to me. That is, I don't see the
> relationship between "patches not even welcome" and degraded performance
> relative to Mozilla-shipped 32-bit x86 Firefox.

If the code doesn't support run-time selection of SSE2 vs. non-SSE2
variants, Mozilla will build the SSE2 variants and a distro that
wishes to support non-SSE2 would build the non-SSE2 code (unless the
distro offers two packages: with SSE2 and without).

> Also note that in practice, there *already* is a performance difference
> between Mozilla-shipped Firefox and distro-shipped Firefox

:-(

> Now, with my Debian hat on, I can tell you with 100% certainty that
> angry Debian users *will* come with patches and will return even
> angrier if patches are not even welcome.

See my reply to bsmedberg above for why I wouldn't want to take
patches for run-time selection of SSE2 in Rust code.

> Why specifically not welcome patches, instead of, say, making it
> tier-3, like e.g. sparc or mips?

MIPS vs. x86 is an app-wide compile-time choice that doesn't involve
splitting crates. I'm against splitting crates for reasons that don't
affect official builds, which is what *run-time* selection of SSE2
would do.

Markus Stange wrote:
> Wouldn't these code paths still be tested on Android? I expect we have many code paths that have an SSE2 specialization but not an ARM NEON one, so we use the non-SSE2 code paths on ARM. The Moz2D software filter code is an example of such a case.

*Compile-time*-selected ALU-only code paths would get tested on Android, yes.

[Kurt Roeckx]

On 2016-05-18 10:10, Henri Sivonen wrote:
> What do we need to do to reach a decision that it's indeed OK to treat
> *run-time* selection of SSE2 vs. non-SSE2 especially in Rust code as a
> "patches not even welcome" kind of thing, considering that this may
> lead to Linux distros shipping an 32-bit x86 "Firefox" with degraded
> performance relative to Mozilla-shipped 32-bit x86 Firefox?

That doesn't make sense, and seems to just have the opposite effect. If
runtime detection is non-optional only non-SSE2 is left. If runtime
detection is supported you wouldn't have degraded performance.


Kurt

[Mike Hommey]

I don't think anyone suggested to add support for runtime selection of
SSE2 for code that is not inline asm.

> The problem with build-time selection is that the non-SSE2 target
> isn't the target that the Rust community tests the most actively.
> (Just like, evidently, Microsoft doesn't actively test the non-SSE
> target of MSVC.)

If distro's Rust compiler doesn't target SSE2, they'll obviously be
testing that. But it's not really a concern for you to have. It's
theirs.

Mike

[Henri Sivonen]

I'm saying patches to add run-time SSE2 selection would not be welcome
for Rust code. I.e. run-time detection would *not* be supported.
Hence, distros that want to support non-SSE2 would compile the
non-SSE2 code only giving SSE2-enabled CPUs non-SSE2 code.

[Henri Sivonen]

On Thu, May 19, 2016 at 12:31 PM, Mike Hommey <m...@glandium.org> wrote:
> I don't think anyone suggested to add support for runtime selection of
> SSE2 for code that is not inline asm.

The code that I'm most immediately interested in replacing with Rust
with SSE2 intrinsics without runtime selection currently uses C++ with
SSE2 intrinsics with runtime selection. It seems prudent to establish
that is indeed is okay to plan to proceed without runtime selection.

[Tobias B. Besemer]

"[...] The earlier 'SIMD' instruction sets on the x86 platform, from oldest to newest, are 'MMX', '3DNow!' (developed by AMD), 'SSE' and 'SSE2'. [...]"
Source: https://en.wikipedia.org/wiki/SSE3 (At the top.)

Is support for 'MMX' & '3DNow!' already dropped?

-BesTo

[Cameron Kaiser]

On 5/18/16 10:41 PM, Jan de Mooij wrote:
>> They do get the baseline compiler, which can still be significantly faster than the interpreter, but Ion requires SSE2. Since the runtime detection does just turn Ion off altogether, I don't know if we would gain much by removing it (the ability to disable Ion isn't going away).
>
>
> We will have to make a similar decision for WebAssembly. Odin (our
> Ion-based asm.js compiler) requires SSE2, but there we can at least
> use the much slower 'normal JS' path. For WebAssembly, we have the
> following options IIUC:
>
> (1) Don't support wasm on those ancient CPUs. This may work for a
> while, but at some point we may include wasm modules in Firefox and
> add-ons, normal websites will start to use it, etc.

You'd also have to make this decision for non-x86/non-ARM. Along with
oxidation that would be a portkiller for the few weird architectures
still hanging on if you didn't do:

> (4) Add a wasm interpreter. Again, likely not worth the effort if it's
> just for this.

One of the really nice things about working with SM is that I can fall
back on the interpreter when things go wrong, and/or use it as a point
of comparison for testing, so doing so has benefits beyond just getting
Tier-3 or unsupported systems functional.

Cameron Kaiser
ein guter Tier-3kenner

[Till Schneidereit]

On Sun, May 22, 2016 at 10:43 PM, Cameron Kaiser <cka...@floodgap.com>
wrote:

I don't know if an interpreter is planned, but there's at least a baseline
compiler in the works:
https://bugzilla.mozilla.org/show_bug.cgi?id=1232205

[Lars Hansen]

The baseline compiler has modest needs and should be able to target a
simple wasm interpreter fairly easily.

--lars

On Sun, May 22, 2016 at 11:08 PM, Till Schneidereit <
ti...@tillschneidereit.net> wrote:

> On Sun, May 22, 2016 at 10:43 PM, Cameron Kaiser <cka...@floodgap.com>
> wrote:
>

> I don't know if an interpreter is planned, but there's at least a baseline
> compiler in the works:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1232205