Does SSE2 usage still need to be conditional?

[Henri Sivonen]

It's been a while since the previous SSE2 thread.

I have some questions:
* Does Firefox (for Windows and Linux) still run on non-SSE2 hardware?
* If it does, do the usage statistics justify it continuing to do so?
* Do Linux distros that ship Firefox by default run on non-SSE2 hardware?
* Do we already use SSE2 code paths unconditionally on x86_64? (I
gather SSE2 is a non-optional part of x86_64.)
* Does Chrome run on non-SSE2 hardware? What about Chromium?

In other words, can SSE2-enablement now be a compile-time thing or
does it still need to be a run-time thing?
--
Henri Sivonen
hsiv...@hsivonen.fi
https://hsivonen.fi/

[Ashley Gullen]

FWIW, the Steam Hardware Survey says 99.99% of users have SSE2 (under
"other settings"): http://store.steampowered.com/hwsurvey

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

[Cameron Kaiser]

On 1/29/16 9:43 AM, Ashley Gullen wrote:
> FWIW, the Steam Hardware Survey says 99.99% of users have SSE2 (under
> "other settings"): http://store.steampowered.com/hwsurvey

For that to be valid, one must assume that the population of Firefox
users and Steam users are sufficiently similar. I don't think that's
necessarily true since most Steam titles have substantially higher
system requirements.

Cameron Kaiser

[Mike Hoye]

While that's a fair point, Microsoft turned compiling with SSE2 on by
default in Visual Studio in 2012, and it's been basically impossible to
buy an x86 CPU without it since... 2004 or so?

I've tapped chutten about this, and he says:

14:33 < chutten> Easy as pie. ping["environment/system/cpu/extensions"]
contains "SSE2"
14:33 < chutten> or, rather, the inverse

... which he then explained to me means "we can get our own data in
short order."

He says it'll be straightforward to pull in, so he's going to do that.


- mhoye

[Chris H-C]

tl;dr - Around 99.5% of Firefox Desktop clients on release channel
represented by (a 20% sample of) pings submitted by on January 21, 2016 had
"hasSSE2" detected.

Here's the analysis and results on github. Please feel free to check my
work: https://gist.github.com/chutten/4959c873d7fbbec0785a

Keep in mind we cannot prove a negative from this. I cannot state that
those pings without hasSSE2 correspond to clients that don't have SSE2
support on their machines. So I tried (and failed, see bottom section of
that gist) to keep analysis and discussion centred on the "hasSSE"
population alone.

:chutten

On Fri, Jan 29, 2016 at 2:44 PM, Mike Hoye <mh...@mozilla.com> wrote:

> On 2016-01-29 2:05 PM, Cameron Kaiser wrote:
>

> While that's a fair point, Microsoft turned compiling with SSE2 on by
> default in Visual Studio in 2012, and it's been basically impossible to buy
> an x86 CPU without it since... 2004 or so?
>
> I've tapped chutten about this, and he says:
>
> 14:33 < chutten> Easy as pie. ping["environment/system/cpu/extensions"]
> contains "SSE2"
> 14:33 < chutten> or, rather, the inverse
>
> ... which he then explained to me means "we can get our own data in short
> order."
>
> He says it'll be straightforward to pull in, so he's going to do that.
>
>
> - mhoye
>

[Kartikaya Gupta]

I also want to highlight the thing at the end of the gist linked above
- the majority of the non-SSE2 population are on 43.0.4. That is,
they're keeping up-to-date, and would likely be affected by this more
than somebody stranded on an old version.

On Fri, Jan 29, 2016 at 3:29 PM, Chris H-C <chu...@mozilla.com> wrote:
> tl;dr - Around 99.5% of Firefox Desktop clients on release channel
> represented by (a 20% sample of) pings submitted by on January 21, 2016 had
> "hasSSE2" detected.
>
> Here's the analysis and results on github. Please feel free to check my
> work: https://gist.github.com/chutten/4959c873d7fbbec0785a
>
> Keep in mind we cannot prove a negative from this. I cannot state that
> those pings without hasSSE2 correspond to clients that don't have SSE2
> support on their machines. So I tried (and failed, see bottom section of
> that gist) to keep analysis and discussion centred on the "hasSSE"
> population alone.
>
> :chutten
>
> On Fri, Jan 29, 2016 at 2:44 PM, Mike Hoye <mh...@mozilla.com> wrote:
>
>> On 2016-01-29 2:05 PM, Cameron Kaiser wrote:
>>

>> While that's a fair point, Microsoft turned compiling with SSE2 on by
>> default in Visual Studio in 2012, and it's been basically impossible to buy
>> an x86 CPU without it since... 2004 or so?
>>
>> I've tapped chutten about this, and he says:
>>
>> 14:33 < chutten> Easy as pie. ping["environment/system/cpu/extensions"]
>> contains "SSE2"
>> 14:33 < chutten> or, rather, the inverse
>>
>> ... which he then explained to me means "we can get our own data in short
>> order."
>>
>> He says it'll be straightforward to pull in, so he's going to do that.
>>
>>
>> - mhoye
>>

[Leman Bennett (Omega X)]

Telemetry doesn't capture this data? One would think that it would be
important to know what the capabilities of your users CPU/GPU at least.

--
==================================
~Omega X

[Milan Sreckovic]

Telemetry reports 99.77% with SSE2…

http://people.mozilla.org/~danderson/moz-gfx-telemetry/www/#view=system <http://people.mozilla.org/~danderson/moz-gfx-telemetry/www/#view=system>

—
- Milan

> On Jan 29, 2016, at 15:33 , Kartikaya Gupta <kgu...@mozilla.com> wrote:
>
> I also want to highlight the thing at the end of the gist linked above
> - the majority of the non-SSE2 population are on 43.0.4. That is,
> they're keeping up-to-date, and would likely be affected by this more
> than somebody stranded on an old version.
>
> On Fri, Jan 29, 2016 at 3:29 PM, Chris H-C <chu...@mozilla.com> wrote:
>> tl;dr - Around 99.5% of Firefox Desktop clients on release channel
>> represented by (a 20% sample of) pings submitted by on January 21, 2016 had
>> "hasSSE2" detected.
>>
>> Here's the analysis and results on github. Please feel free to check my
>> work: https://gist.github.com/chutten/4959c873d7fbbec0785a
>>
>> Keep in mind we cannot prove a negative from this. I cannot state that
>> those pings without hasSSE2 correspond to clients that don't have SSE2
>> support on their machines. So I tried (and failed, see bottom section of
>> that gist) to keep analysis and discussion centred on the "hasSSE"
>> population alone.
>>
>> :chutten
>>
>> On Fri, Jan 29, 2016 at 2:44 PM, Mike Hoye <mh...@mozilla.com> wrote:
>>
>>> On 2016-01-29 2:05 PM, Cameron Kaiser wrote:
>>>

>>> While that's a fair point, Microsoft turned compiling with SSE2 on by
>>> default in Visual Studio in 2012, and it's been basically impossible to buy
>>> an x86 CPU without it since... 2004 or so?
>>>
>>> I've tapped chutten about this, and he says:
>>>
>>> 14:33 < chutten> Easy as pie. ping["environment/system/cpu/extensions"]
>>> contains "SSE2"
>>> 14:33 < chutten> or, rather, the inverse
>>>
>>> ... which he then explained to me means "we can get our own data in short
>>> order."
>>>
>>> He says it'll be straightforward to pull in, so he's going to do that.
>>>
>>>
>>> - mhoye
>>>

[Benjamin Smedberg]

The last time we broke this (by accident) was several years ago. At the
time, we got vigorous complaining from various people who had relatively
recent bare-bones machines without SSE2.

It might be worth reconsidering now: I'm not willing to throw away 0.5%
of our users without good cause, but perhaps there is a good cause to be
made here? What would the performance gain be for the remaining 99.5% of
users, realizing that we already have dynamic SSE2/non-SSE switching in
place for some of our hottest paths.

--BDS

[Xidorn Quan]

On Tue, Feb 2, 2016 at 7:04 AM, Benjamin Smedberg <benj...@smedbergs.us> wrote:
>
>
> On 1/29/2016 2:05 PM, Cameron Kaiser wrote:
>>

> The last time we broke this (by accident) was several years ago. At the
> time, we got vigorous complaining from various people who had relatively
> recent bare-bones machines without SSE2.
>
> It might be worth reconsidering now: I'm not willing to throw away 0.5% of
> our users without good cause, but perhaps there is a good cause to be made
> here? What would the performance gain be for the remaining 99.5% of users,
> realizing that we already have dynamic SSE2/non-SSE switching in place for
> some of our hottest paths.

The main question here I think is, whether we've enabled SSE2 for 64bit build

It seems to me if we do, whether enabling SSE2 on x86 doesn't really
matter unless we have a good reason. Fewer and fewer people would
stick on x86, especially who cares about performance.

If we haven't yet done that, we should. It seems to me the majority
processors which supports x64 also supports SSE2. If there are really
some people who use a processor doesn't support SSE2 but are using
64bit Firefox, they could simply back to use the 32bit version.

- Xidorn

[Jeff Muizelaar]

I don't think there are any compilers that support x64 without SSE2.
SSE2 registers are required for passing float parameters in both MS
and System V ABIs.

-Jeff

On Mon, Feb 1, 2016 at 6:00 PM, Xidorn Quan <quanx...@gmail.com> wrote:
> On Tue, Feb 2, 2016 at 7:04 AM, Benjamin Smedberg <benj...@smedbergs.us> wrote:
>>
>>
>> On 1/29/2016 2:05 PM, Cameron Kaiser wrote:
>>>

>> The last time we broke this (by accident) was several years ago. At the
>> time, we got vigorous complaining from various people who had relatively
>> recent bare-bones machines without SSE2.
>>
>> It might be worth reconsidering now: I'm not willing to throw away 0.5% of
>> our users without good cause, but perhaps there is a good cause to be made
>> here? What would the performance gain be for the remaining 99.5% of users,
>> realizing that we already have dynamic SSE2/non-SSE switching in place for
>> some of our hottest paths.
>
> The main question here I think is, whether we've enabled SSE2 for 64bit build
>
> It seems to me if we do, whether enabling SSE2 on x86 doesn't really
> matter unless we have a good reason. Fewer and fewer people would
> stick on x86, especially who cares about performance.
>
> If we haven't yet done that, we should. It seems to me the majority
> processors which supports x64 also supports SSE2. If there are really
> some people who use a processor doesn't support SSE2 but are using
> 64bit Firefox, they could simply back to use the 32bit version.
>
> - Xidorn

[Marco]

SSE2 is always available in 64bit CPUs, it's included in the AMD64
specification.
So I'd be surprised if compilers didn't automatically use SSE2 for 64bit
targets.

Another interesting data point is that Windows 8.1 doesn't work without
SSE2 [1],
but I guess most people that use Windows 8.1 have a 64bit CPU.

[1] http://windows.microsoft.com/en-GB/windows-8/what-is-pae-nx-sse2

- Marco.

Il 01/02/16 15:00, Xidorn Quan ha scritto:

> On Tue, Feb 2, 2016 at 7:04 AM, Benjamin Smedberg <benj...@smedbergs.us> wrote:
>>
>> On 1/29/2016 2:05 PM, Cameron Kaiser wrote:

[Milan Sreckovic]

> On Feb 1, 2016, at 18:00 , Xidorn Quan <quanx...@gmail.com> wrote:
> ...

>
> It seems to me if we do, whether enabling SSE2 on x86 doesn't really
> matter unless we have a good reason. Fewer and fewer people would
> stick on x86, especially who cares about performance.

Surprisingly, perhaps, there are a lot of people using Firefox on 32-bit Windows. If I’m reading the data correctly, more than half. A small percentage of those don’t have SSE2.

>
> If we haven't yet done that, we should. It seems to me the majority
> processors which supports x64 also supports SSE2. If there are really
> some people who use a processor doesn't support SSE2 but are using
> 64bit Firefox, they could simply back to use the 32bit version.
>
> - Xidorn

[Xidorn Quan]

On Tue, Feb 2, 2016 at 10:42 AM, Milan Sreckovic <msrec...@mozilla.com> wrote:
>
>> On Feb 1, 2016, at 18:00 , Xidorn Quan <quanx...@gmail.com> wrote:
>> ...
>>
>> It seems to me if we do, whether enabling SSE2 on x86 doesn't really
>> matter unless we have a good reason. Fewer and fewer people would
>> stick on x86, especially who cares about performance.
>
> Surprisingly, perhaps, there are a lot of people using Firefox on 32-bit Windows. If I’m reading the data correctly, more than half. A small percentage of those don’t have SSE2.

It's not surprising to me. We didn't have Firefox release for Win64
until recent, and we haven't ever pushed users with 64bit Windows to
use that version, which we probably should at some point, given the
significant performance improvement.

- Xidorn

[Mike Hommey]

On Mon, Feb 01, 2016 at 06:42:30PM -0500, Milan Sreckovic wrote:
>
> > On Feb 1, 2016, at 18:00 , Xidorn Quan <quanx...@gmail.com>
> > wrote: ...
> >
> > It seems to me if we do, whether enabling SSE2 on x86 doesn't really
> > matter unless we have a good reason. Fewer and fewer people would
> > stick on x86, especially who cares about performance.
>
> Surprisingly, perhaps, there are a lot of people using Firefox on
> 32-bit Windows. If I’m reading the data correctly, more than half. A
> small percentage of those don’t have SSE2.

64-bits Firefox was only officially released recently, and AFAIK, we're not
offering 32-bits Firefox users an upgrade to 64-bits Firefox if their
system permits. How about we started doing that?

Mike

[Nicholas Nethercote]

On Tue, Feb 2, 2016 at 10:55 AM, Xidorn Quan <quanx...@gmail.com> wrote:
>>
>> Surprisingly, perhaps, there are a lot of people using Firefox on 32-bit Windows. If I’m reading the data correctly, more than half. A small percentage of those don’t have SSE2.
>

> It's not surprising to me. We didn't have Firefox release for Win64 until recent,
> and we haven't ever pushed users with 64bit Windows to use that version,

There are three Windows configurations, AIUI:

a) 32-bit Firefox on 32-bit Windows
b) 32-bit Firefox on 64-bit Windows
c) 64-bit Firefox on 64-bit Windows

I think Milan is talking about (a) and Xidorn is talking about (b) vs. (c).

This discussion will be more productive if everyone is clear about
which configurations they mean. Thanks.

Nick

[Xidorn Quan]

Thanks for making it clear, and sorry for misreading the email.

So Milan, did you mean there are over half of people using 32bit
Windows not just 32bit Firefox? Is there any data we can see for this?

Looked at Telemetry, and found an item called
DEVTOOLS_OS_IS_64_BITS_PER_USER, which according to the code, actually
checks whether the build is 64bit, not the system. (That checks
eventually goes to nsXULAppInfo::GetIs64Bit(), which returns value
depends on a compile time macro.)

- Xidorn

[Chris Peterson]

On 2/1/16 3:56 PM, Mike Hommey wrote:
> 64-bits Firefox was only officially released recently, and AFAIK, we're not
> offering 32-bits Firefox users an upgrade to 64-bits Firefox if their
> system permits. How about we started doing that?

There are two steps planned to bring 64-bit Firefox to normal release users:

* A "universal" stub installer that downloads 32-bit or 64-bit Firefox,
depending on the user's OS, for new installs.

* Auto-upgrading existing 32-bit users to 64-bit.

This work was planned for 2016, but I don't know the current state.

The primary concerns are NPAPI plugins and add-on compatibility. We only
support Flash and Silverlight on 64-bit Firefox. If a user doesn't have
any other plugins installed, or if they haven't used their other plugins
in N months, perhaps they could be upgraded without problem.


chris

[Martin Thomson]

On Tue, Feb 2, 2016 at 10:42 AM, Milan Sreckovic <msrec...@mozilla.com> wrote:
> Surprisingly, perhaps, there are a lot of people using Firefox on 32-bit Windows. If I’m reading the data correctly, more than half. A small percentage of those don’t have SSE2.

Do we have any, say telemetry, that would move this from speculation
into numbers? Sure, numbers aren't necessarily perfect, but I'm sure
that they would help.

[Xidorn Quan]

On Tue, Feb 2, 2016 at 11:31 AM, Chris Peterson <cpet...@mozilla.com> wrote:
> On 2/1/16 3:56 PM, Mike Hommey wrote:
>> 64-bits Firefox was only officially released recently, and AFAIK, we're not
>> offering 32-bits Firefox users an upgrade to 64-bits Firefox if their
>> system permits. How about we started doing that?
>
> There are two steps planned to bring 64-bit Firefox to normal release users:
>
> * A "universal" stub installer that downloads 32-bit or 64-bit Firefox,
> depending on the user's OS, for new installs.
>
> * Auto-upgrading existing 32-bit users to 64-bit.
>
> This work was planned for 2016, but I don't know the current state.

Cool!

I have an idea that, after we have this, we could further divide the
64bit version into two versions, e.g. one with basic 64bit, the other
with more instruction sets enabled, so that more optimization could be
done.

If we would like to do this, we would probably need data including the
percentage of users are on hardware supports each instruction set, and
how much performance gain we would get for enabling each level of
instruction set.

It probably would turn out this isn't really worth the effort, though.
I think it is at least worth benchmarking how fast a Firefox build
with, e.g. AVX enabled, could be.

- Xidorn

[Benjamin Smedberg]

Milan is quoting numbers from telemetry data. The last time I calculated
this was 8 months ago, but at the time our users were using an almost
50/50 split of 32-bit Windows and 64-bit Windows. We expect that number
to grow slowly over time with the device replacement cycle.

--BDS

[Milan Sreckovic]

Right, what Benjamin said - the “if I’m reading the data correctly” meant I was looking at the telemetry results from the same link that I included in one of the earlier replies: http://people.mozilla.org/~danderson/moz-gfx-telemetry/www/#view=system

51.9% 32-bit Firefox on 32-bit Windows
44.7% 32-bit Firefox on 64-bit Windows
3.5% 64-bit Firefox on 64-bit Windows

—
- Milan

[Martin Thomson]

On Wed, Feb 3, 2016 at 12:54 AM, Benjamin Smedberg
<benj...@smedbergs.us> wrote:
>> Do we have any, say telemetry, that would move this from speculation
>> into numbers? Sure, numbers aren't necessarily perfect, but I'm sure
>> that they would help.
>
> Milan is quoting numbers from telemetry data. The last time I calculated
> this was 8 months ago, but at the time our users were using an almost 50/50
> split of 32-bit Windows and 64-bit Windows. We expect that number to grow
> slowly over time with the device replacement cycle.

I'm afraid that those numbers don't answer the question that is asked,
namely: does the user have SSE2? I suspect that a very large
proportion of users on 32-bit systems with 32-bit builds will still
have a 64-bit processor. Far more than 48%, that is.

[Henri Sivonen]

On Fri, Jan 29, 2016 at 10:29 PM, Chris H-C <chu...@mozilla.com> wrote:
> tl;dr - Around 99.5% of Firefox Desktop clients on release channel
> represented by (a 20% sample of) pings submitted by on January 21, 2016 had
> "hasSSE2" detected.
>
> Here's the analysis and results on github. Please feel free to check my
> work: https://gist.github.com/chutten/4959c873d7fbbec0785a

Thank you. Do I read this correctly that the percentage is calculated
relative to all installations that send telemetry and not just
relative to 32-bit x86?

On Mon, Feb 1, 2016 at 10:04 PM, Benjamin Smedberg
<benj...@smedbergs.us> wrote:
> It might be worth reconsidering now: I'm not willing to throw away 0.5% of
> our users without good cause, but perhaps there is a good cause to be made
> here? What would the performance gain be for the remaining 99.5% of users,
> realizing that we already have dynamic SSE2/non-SSE switching in place for
> some of our hottest paths.

My interest is two-fold:

First, I'm working on some Rust code with the intent of getting it
into Gecko unconditionally on all platforms. It seems that the
official Rust toolchain for 32-bit x86 feels free to generate SSE2
instructions (for floating point or, I suppose, whenever the LLVM
autovectorizer decides to use SSE2). My understanding is that the new
MP4 demuxer that's written in Rust is currently only being built in
the x86_64 case, so, AFAICT (I'd love to be wrong!), Rust code in
32-bit Firefox isn't a solved problem yet.

For Rust code that doesn't explicitly try to use SSE2, are we going to
use the default official rustc which emits SSE2-requiring code and,
therefore, make Firefox require SSE2 on 32-bit x86? Or are we going to
use rustc in a non-default configuration so that SSE2 instructions are
absent in its output and, therefore, we'd ship using a non-default
compiler config? (I'm hoping this gets decided before figuring it out
becomes a blocker. If it has been already figured out, awesome.)

Second, the Rust code that I'm working on would (if things go like I
hope) replace C++ code that has an explicitly SSE2-optimized code
path. If we decide that rustc isn't allowed to emit SSE2
unconditionally, I'd need to figure out how to choose from SSE2 and
non-SSE2 function implementations at run time. AFAICT, this would
entail compiling the SSE2-enabled function as a separate crate and
have the two Rust crates see each other as C code behind the FFI. I'd
rather not put in the effort if we are on the verge of just allowing
SSE2 unconditionally.

As for the consequences of requiring SSE2 unconditionally, I'm
personally more worried about a conflict with Linux distros that don't
already require SSE2 (even if near 100% of their users actually had
SSE2-enabled hardware; this concern is not about the actual numbers)
than about dropping support for XP boxes. Curiously, Fedora seems to
document that llvmpipe requires SSE2 as if the distro as a whole
didn't. I wonder if there actually exist non-SSE2 boxes with
Gnome3-compatible OpenGL on the GPU. Ubuntu also relies on llvmpipe in
the absence of suitable GPU-base OpenGL support. This suggests that
the major distros are de facto pretty far along requiring SSE2, but I
don't know what their policies are and how unhappy they'd be about
Firefox requiring SSE2 (or how unhappy we'd be if distros shipped
de-optimized Firefox and users thought it works the same as the one
from Mozilla).

[Kurt Roeckx]

On 2016-02-03 14:23, Henri Sivonen wrote:
> As for the consequences of requiring SSE2 unconditionally, I'm
> personally more worried about a conflict with Linux distros that don't
> already require SSE2 (even if near 100% of their users actually had
> SSE2-enabled hardware; this concern is not about the actual numbers)
> than about dropping support for XP boxes. Curiously, Fedora seems to
> document that llvmpipe requires SSE2 as if the distro as a whole
> didn't. I wonder if there actually exist non-SSE2 boxes with
> Gnome3-compatible OpenGL on the GPU. Ubuntu also relies on llvmpipe in
> the absence of suitable GPU-base OpenGL support. This suggests that
> the major distros are de facto pretty far along requiring SSE2, but I
> don't know what their policies are and how unhappy they'd be about
> Firefox requiring SSE2 (or how unhappy we'd be if distros shipped
> de-optimized Firefox and users thought it works the same as the one
> from Mozilla).

As far as I know in Debian i386 just changed it's default from i586 to
i686 (+ cmov?):
https://lists.debian.org/debian-devel/2015/09/msg00589.html

There are some packages that do unconditionally use things like sse2,
but they're usually specialized and you wouldn't run it on old hardware.

I have no idea what the situation with things like llvmpipe is.


Kurt

[Ehsan Akhgari]

On 2016-02-03 8:23 AM, Henri Sivonen wrote:
> For Rust code that doesn't explicitly try to use SSE2, are we going to
> use the default official rustc which emits SSE2-requiring code and,
> therefore, make Firefox require SSE2 on 32-bit x86? Or are we going to
> use rustc in a non-default configuration so that SSE2 instructions are
> absent in its output and, therefore, we'd ship using a non-default
> compiler config? (I'm hoping this gets decided before figuring it out
> becomes a blocker. If it has been already figured out, awesome.)

The rust driver added support for target-feature here:
<https://github.com/rust-lang/rust/pull/5996> This allows control over
the target features the LLVM codegen assumes. It seems like passing -C
target-feature=-sse2 will make rust not emit SSE2 instructions (but I
haven't tested this.)

Do you mind giving this a shot?

[Chris H-C]

So I reran the analysis, this time breaking down by OS the users who we
can't say for certain have SSE2:
https://gist.github.com/chutten/e4ccd0d5a46b782bae53

This was on a 25% sample of users reporting in from release Firefox on Jan
21.

The tl;dr is that it's mostly WinXP. So much so that it's almost correct to
say that it's _only_ WinXP.

:chutten

On Wed, Feb 3, 2016 at 9:41 AM, Ehsan Akhgari <ehsan....@gmail.com>
wrote:

[Milan Sreckovic]

Right - I mentioned the number earlier, but let me summarize:

99.77% of the users on all channels have SSE2 support;
51.7% of all users are on 32-bit Windows;
0.44% of all users on 32-bit Windows do not have SSE2 support.

—
- Milan

[Ralph Giles]

On Wed, Feb 3, 2016 at 5:23 AM, Henri Sivonen <hsiv...@hsivonen.fi> wrote:

> My understanding is that the new
> MP4 demuxer that's written in Rust is currently only being built in
> the x86_64 case, so, AFAICT (I'd love to be wrong!), Rust code in
> 32-bit Firefox isn't a solved problem yet.

We're actually building it for 32-bit MacOS X too, but all x86 macs have SSE2.

> As for the consequences of requiring SSE2 unconditionally, I'm
> personally more worried about a conflict with Linux distros that don't
> already require SSE2

Do you know if rust's unwind will catch illegal instructions? The mp4
demuxer code currently runs in an isolation thead so panics don't
affect the firefox process. So I'm wondering if we could enable this
for linux32 with telemetry to get a measurement outside crash reports.

-r

[Martin Thomson]

On Thu, Feb 4, 2016 at 2:21 AM, Milan Sreckovic <msrec...@mozilla.com> wrote:
> 99.77% of the users on all channels have SSE2 support;
> 51.7% of all users are on 32-bit Windows;
> 0.44% of all users on 32-bit Windows do not have SSE2 support.

Those numbers wouldn't justify a change to me. When we make decisions
about what we break with TLS by disabling something that is maybe
dangerous, we try to avoid changes that break any more than 0.1% of
our population. It looks like we are almost there, but unlike some of
the security changes, we can't just provide motivation to change [1]
because requesting a hardware change is a pretty high bar to clear.

[1] The normal process is announcements about deprecation, blog
postings about how X is or might be broken, etc...

[Ehsan Akhgari]

On 2016-02-03 12:50 PM, Martin Thomson wrote:
> On Thu, Feb 4, 2016 at 2:21 AM, Milan Sreckovic <msrec...@mozilla.com> wrote:
>> 99.77% of the users on all channels have SSE2 support;
>> 51.7% of all users are on 32-bit Windows;
>> 0.44% of all users on 32-bit Windows do not have SSE2 support.
>
> Those numbers wouldn't justify a change to me. When we make decisions
> about what we break with TLS by disabling something that is maybe
> dangerous, we try to avoid changes that break any more than 0.1% of
> our population. It looks like we are almost there, but unlike some of
> the security changes, we can't just provide motivation to change [1]
> because requesting a hardware change is a pretty high bar to clear.

As I said elsewhere in the thread, we can just pass the correct flag to
rustc to select the correct target features. Dropping support for old
processors seems to be orthogonal to what Henri wants to do in rust.

[Bobby Holley]

On Wed, Feb 3, 2016 at 10:32 AM, Ehsan Akhgari <ehsan....@gmail.com>
wrote:

Except for the fact that the code he wants to replace uses dynamic SSE
switching for the hot code, which seems difficult to do when dropping in a
rust replacement, right?

[Ehsan Akhgari]

On 2016-02-03 1:41 PM, Bobby Holley wrote:
>
>
> On Wed, Feb 3, 2016 at 10:32 AM, Ehsan Akhgari <ehsan....@gmail.com
> <mailto:ehsan....@gmail.com>> wrote:
>
> On 2016-02-03 12:50 PM, Martin Thomson wrote:
>
> On Thu, Feb 4, 2016 at 2:21 AM, Milan Sreckovic
> <msrec...@mozilla.com <mailto:msrec...@mozilla.com>> wrote:
>
> 99.77% of the users on all channels have SSE2 support;
> 51.7% of all users are on 32-bit Windows;
> 0.44% of all users on 32-bit Windows do not have SSE2 support.
>
>
> Those numbers wouldn't justify a change to me. When we make
> decisions
> about what we break with TLS by disabling something that is maybe
> dangerous, we try to avoid changes that break any more than 0.1% of
> our population. It looks like we are almost there, but unlike
> some of
> the security changes, we can't just provide motivation to change [1]
> because requesting a hardware change is a pretty high bar to clear.
>
>
> As I said elsewhere in the thread, we can just pass the correct flag
> to rustc to select the correct target features. Dropping support
> for old processors seems to be orthogonal to what Henri wants to do
> in rust.
>
>
> Except for the fact that the code he wants to replace uses dynamic SSE
> switching for the hot code, which seems difficult to do when dropping in
> a rust replacement, right?

Can't we build one file with target-features=-sse2 and one with
target-features=+sse2?

[Mike Hommey]

On Wed, Feb 03, 2016 at 10:41:03AM -0800, Bobby Holley wrote:
> On Wed, Feb 3, 2016 at 10:32 AM, Ehsan Akhgari <ehsan....@gmail.com>

> wrote:
>
> > On 2016-02-03 12:50 PM, Martin Thomson wrote:
> >
> >> On Thu, Feb 4, 2016 at 2:21 AM, Milan Sreckovic <msrec...@mozilla.com>

> >> wrote:
> >>
> >>> 99.77% of the users on all channels have SSE2 support;
> >>> 51.7% of all users are on 32-bit Windows;
> >>> 0.44% of all users on 32-bit Windows do not have SSE2 support.
> >>>
> >>
> >> Those numbers wouldn't justify a change to me. When we make decisions
> >> about what we break with TLS by disabling something that is maybe
> >> dangerous, we try to avoid changes that break any more than 0.1% of
> >> our population. It looks like we are almost there, but unlike some of
> >> the security changes, we can't just provide motivation to change [1]
> >> because requesting a hardware change is a pretty high bar to clear.
> >>
> >
> > As I said elsewhere in the thread, we can just pass the correct flag to
> > rustc to select the correct target features. Dropping support for old
> > processors seems to be orthogonal to what Henri wants to do in rust.
>
>
> Except for the fact that the code he wants to replace uses dynamic SSE
> switching for the hot code, which seems difficult to do when dropping in a
> rust replacement, right?

GCC has a target __attribute__ that allows to selectively enable e.g.
SSE per function (which, btw, we could use for C++ instead of using
separate sources built with different flags, although I don't know if
clang or MSVC support the same thing or similar).
Rust could (should) grow something similar.

Mike

[Henri Sivonen]

On Wed, Feb 3, 2016 at 4:58 PM, Chris H-C <chu...@mozilla.com> wrote:
> So I reran the analysis, this time breaking down by OS the users who we
> can't say for certain have SSE2:
> https://gist.github.com/chutten/e4ccd0d5a46b782bae53
>
> This was on a 25% sample of users reporting in from release Firefox on Jan
> 21.
>
> The tl;dr is that it's mostly WinXP. So much so that it's almost correct to
> say that it's _only_ WinXP.

Thank you.

It looks like this will be yet another way for XP to be a time sink. :-(

(I'm all for user retention, but when it comes to doing XP-specific
engineering, one has to wonder if more forward-looking efforts would
be a better use of limited resources.)

On Wed, Feb 3, 2016 at 7:41 PM, Ralph Giles <gi...@mozilla.com> wrote:
> On Wed, Feb 3, 2016 at 5:23 AM, Henri Sivonen <hsiv...@hsivonen.fi> wrote:
>
>> My understanding is that the new
>> MP4 demuxer that's written in Rust is currently only being built in
>> the x86_64 case, so, AFAICT (I'd love to be wrong!), Rust code in
>> 32-bit Firefox isn't a solved problem yet.
>
> We're actually building it for 32-bit MacOS X too, but all x86 macs have SSE2.

Is there a plan for adding Android builds and 32-bit Windows and Linux builds?

>> As for the consequences of requiring SSE2 unconditionally, I'm
>> personally more worried about a conflict with Linux distros that don't
>> already require SSE2
>
> Do you know if rust's unwind will catch illegal instructions?

I don't.

> The mp4
> demuxer code currently runs in an isolation thead so panics don't
> affect the firefox process. So I'm wondering if we could enable this
> for linux32 with telemetry to get a measurement outside crash reports.

To be clear, I'm less worried about Linux users having non-SSE2
hardware (chutten's numbers suggest we don't need to worry about that)
than I am about violating Linux distros' policies (that may be out of
date relative to hardware reality). That is, a policy violation might
result in drama even if the violation didn't affect a notable user
population in practice.

On Wed, Feb 3, 2016 at 9:23 PM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
> Can't we build one file with target-features=-sse2 and one with
> target-features=+sse2?

If the two Rust crates see each other through the C ABI, yes (with
s/file/crate/, since the compilation unit in Rust is a crate and not a
file). AFAICT, using Rust linkage, no, due to the limitations of the
Rust integration into the Firefox build system. (That's a problem for
other reasons, too. I'll start a new thread about cross-crate Rust
linkage in Gecko.)

On Thu, Feb 4, 2016 at 12:17 AM, Mike Hommey <m...@glandium.org> wrote:
> GCC has a target __attribute__ that allows to selectively enable e.g.
> SSE per function (which, btw, we could use for C++ instead of using
> separate sources built with different flags, although I don't know if
> clang or MSVC support the same thing or similar).
> Rust could (should) grow something similar.

According to https://users.rust-lang.org/t/is-there-a-way-to-set-per-function-compiler-options/4524/5
, rustc is blocked on LLVM developing the back end functionality.

[Ralph Giles]

On Thu, Feb 4, 2016 at 11:45 PM, Henri Sivonen <hsiv...@hsivonen.fi> wrote:

>> We're actually building it for 32-bit MacOS X too, but all x86 macs have SSE2.
>
> Is there a plan for adding Android builds and 32-bit Windows and Linux builds?

We plan to do so. Nathan Froyd has been working on both of those.
Win32 is blocked on SAFESEH generation and possibly some msvc unwind
changes coming in rust 1.8.

https://bugzilla.mozilla.org/show_bug.cgi?id=1184732 (windows)
https://bugzilla.mozilla.org/show_bug.cgi?id=1220307 (android)

> To be clear, I'm less worried about Linux users having non-SSE2
> hardware (chutten's numbers suggest we don't need to worry about that)
> than I am about violating Linux distros' policies (that may be out of
> date relative to hardware reality). That is, a policy violation might
> result in drama even if the violation didn't affect a notable user
> population in practice.

Would it result in drama if it's just a bug with an easy fix? Distros'
support policies are different from ours as their upstream. Perhaps we
should just try it without the `-C target-feature=-sse2` for linux32,
but pass it for win32?

-r

[Ralph Giles]

On Fri, Feb 5, 2016 at 10:31 AM, Ralph Giles <gi...@mozilla.com> wrote:

> Would it result in drama if it's just a bug with an easy fix? Distros'
> support policies are different from ours as their upstream. Perhaps we
> should just try it without the `-C target-feature=-sse2` for linux32,
> but pass it for win32?

Turns out we got pretty instant feedback on win32.
https://bugzilla.mozilla.org/show_bug.cgi?id=1252041

[Henri Sivonen]

On Mon, Feb 1, 2016 at 10:04 PM, Benjamin Smedberg
<benj...@smedbergs.us> wrote:
> It might be worth reconsidering now: I'm not willing to throw away 0.5% of
> our users without good cause, but perhaps there is a good cause to be made
> here? What would the performance gain be for the remaining 99.5% of users,
> realizing that we already have dynamic SSE2/non-SSE switching in place for
> some of our hottest paths.

For performance, we'd be able to enable SSE2 autovectorization for all
the code that doesn't use SSE2 explicitly and, as I understand it, for
consistency in e.g. graphics behavior, we could use SSE2 instructions
for non-vectorized floating-point math to get IEEE-compliant results
instead of Intel legacy results even on x86.

In order to enable measurement, I filed
https://bugzilla.mozilla.org/show_bug.cgi?id=1265366 to request build
system support for building with SSE2 autovectorization and
floating-point math.