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

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

On Mon, May 16, 2016 at 9:14 PM, Ralph Giles  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
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform