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

[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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: the looming wasm chasm was Re: Requiring SSE2 on all 32-bit x86 OSs

[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 <
t...@tillschneidereit.net> wrote:

> On Sun, May 22, 2016 at 10:43 PM, Cameron Kaiser 
> wrote:
>
> > 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.
> >
>
> 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
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: the looming wasm chasm was Re: Requiring SSE2 on all 32-bit x86 OSs

[Till Schneidereit]

On Sun, May 22, 2016 at 10:43 PM, Cameron Kaiser 
wrote:

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

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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

the looming wasm chasm was Re: Requiring SSE2 on all 32-bit x86 OSs

[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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Requiring SSE2 on all 32-bit x86 OSs

[Henri Sivonen]

On Thu, May 19, 2016 at 12:31 PM, Mike Hommey  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.

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Henri Sivonen]

On Thu, May 19, 2016 at 12:30 PM, Kurt Roeckx  wrote:
> 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.

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
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[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

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Requiring SSE2 on all 32-bit x86 OSs

[Mike Hommey]

On Thu, May 19, 2016 at 12:07:42PM +0300, Henri Sivonen wrote:
> On Wed, May 18, 2016 at 8:32 PM, Benjamin Smedberg
>  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.

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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Requiring SSE2 on all 32-bit x86 OSs

[Henri Sivonen]

On Wed, May 18, 2016 at 8:32 PM, Benjamin Smedberg
 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  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.

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Jan de Mooij]

On Thu, May 19, 2016 at 2:59 AM, Emanuel Hoogeveen <
emanuel.hoogev...@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).
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Jan de Mooij]

On Thu, May 19, 2016 at 2:59 AM, Emanuel Hoogeveen
 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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[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).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Tobias B. Besemer]

Am Mittwoch, 18. Mai 2016 20:28:01 UTC+2 schrieb 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... ;-)

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.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Requiring SSE2 on all 32-bit x86 OSs

[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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Jim Blandy]

On Wed, May 18, 2016 at 9:51 AM, Ralph Giles  wrote:

> On Wed, May 18, 2016 at 3:54 AM, Mike Hommey  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.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[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... ;-)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[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  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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Benjamin Smedberg]

On Wed, May 18, 2016 at 6:54 AM, Mike Hommey  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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

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



On Wed, May 18, 2016 at 8:50 AM, Tobias B. Besemer <
tobias.bese...@googlemail.com> wrote:

> Am Mittwoch, 18. Mai 2016 16:52:25 UTC+2 schrieb 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
>
> 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...)
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Tobias B. Besemer]

Am Mittwoch, 18. Mai 2016 16:52:25 UTC+2 schrieb 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

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...)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Requiring SSE2 on all 32-bit x86 OSs

[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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Tobias B. Besemer]

Am Mittwoch, 18. Mai 2016 13:56:14 UTC+2 schrieb Tobias B. Besemer:
> Am Mittwoch, 18. Mai 2016 13:38:58 UTC+2 schrieb 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
> 
> ...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.

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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Tobias B. Besemer]

Am Mittwoch, 18. Mai 2016 13:38:58 UTC+2 schrieb 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

...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.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Mike Hommey]

On Wed, May 18, 2016 at 11:10:30AM +0300, Henri Sivonen wrote:
> On Mon, May 16, 2016 at 8:53 PM, Benjamin Smedberg
>  wrote:
> > On Mon, May 16, 2016 at 8:47 AM, Henri Sivonen  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?

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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform