Time to revive the "require SSE2" discussion

[Boris Zbarsky]

We last talked about this on this list in Dec 2009, I think.

Summary: we could get some performance benefits by compiling with the
assumption that the hardware we run on has SSE2 support. The only
drawback is that this is false for some middling-old AMD hardware.

Additional information since last time:

1) We definitely know we have users on such hardware: see
https://bugzilla.mozilla.org/show_bug.cgi?id=712261

2) As that bug points out, such users no longer have a JS JIT at all as
of Firefox 9, and have had a semi-crippled one since Firefox 4
(Tracemonkey did not require SSE2, but JaegerMonkey does).

So at this point these users are getting a terrible user experience from
us anyway. :(

For comparison, I believe that Chrome does in fact assume that SSE2 is
available at runtime. See
<http://code.google.com/p/chromium/issues/detail?id=9007>. I'm not sure
about other UAs.

-Boris

[Justin Lebar]

Can we quantify the performance improvement of compiling with -msse2?

-Justin

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

[Boris Zbarsky]

On 12/24/11 1:25 PM, Justin Lebar wrote:
> Can we quantify the performance improvement of compiling with -msse2?

At the very least we can do some try pushes, right? I'm glad to do that
if someone tells me how to trigger that mode on Windows.

-Boris

[Boris Zbarsky]

On 12/24/11 1:25 PM, Justin Lebar wrote:

> Can we quantify the performance improvement of compiling with -msse2?

Oh, and a rough cut is at http://www.palemoon.org/technical.shtml#speed

Not clear how much of that is -msse2 and how much is whatever else they
do, but I suspect it's mostly the former. Summary is not much change
for jitcode (no surprise, of course), and 10-25% wins elsewhere. I
would expect our testing to show a slightly smaller win, probably. ;)

-Boris

[djc...@gmail.com]

What percentage of users currently don't have SSE2 support? I believe it's possible to estimate this from the CPU information in crash reports?

[Boris Zbarsky]

OK, so we have:

No SSE2: https://tbpl.mozilla.org/?tree=Try&rev=08e1a5a6afc0
SSE2: https://tbpl.mozilla.org/?tree=Try&rev=4f81468ed6a5

Compare-talos is busted, so I'm just going to mention the things I
looked at. All were on the "Win opt" build; there seemed to be little
to no win on Linux from SSE2.

Tp: no change
Dromaeo DOM: maybe 2% win
Dromaeo CSS: maybe 2.5% win
Tdhtml: no change

I didn't try running Peacekeeper.

Now it could be that the difference between the above and the Palemoon
numbers is arch differences: their speed tests are on a single-core
2.4GHz machine (almost certainly a P4), which could have a much
different relationship between SSE2 and x87 instructions than the
hardware we test on (and that our users use).

So pending some other sort of data, doesn't look like this would be a
huge win...

The bigger question is whether we're ok shipping the subpar JIT-less
browsing experience to people.

-Boris

[Justin Wood (Callek)]

Boris Zbarsky wrote:
> The bigger question is whether we're ok shipping the subpar JIT-less
> browsing experience to people.

Few Questions to help "us" infer this decision line:

* What happens when a user tries to launch our "assume SSE2" builds when
they don't have a machine that supports SSE2 (both linux and win?)

* Do we have a method to identify if a user has SSE2 prior to the update?
** If not now, is it possible to design a way without much overhead that
we can pass on to the update server?

* Do we gain any coding simplicity overall with this tuned as our base
assumption?

* Does IE 9+ work on machines without SSE2? [if not too hard to gather
info for]

* Does us doing this on desktop builds have *any* affect on our Mobile
story?

--
~Justin Wood (Callek)

[Kyle Huey]

On Sun, Dec 25, 2011 at 9:10 PM, Justin Wood (Callek) <Cal...@gmail.com>wrote:

> Boris Zbarsky wrote:
>
>> The bigger question is whether we're ok shipping the subpar JIT-less
>> browsing experience to people.
>>
>
> Few Questions to help "us" infer this decision line:
>
> * What happens when a user tries to launch our "assume SSE2" builds when
> they don't have a machine that supports SSE2 (both linux and win?)
>

We'd put in a check and abort at startup that pops up a dialog or something.

> * Do we have a method to identify if a user has SSE2 prior to the update?
>

Not currently.

> ** If not now, is it possible to design a way without much overhead that
> we can pass on to the update server?
>

Yes.

> * Do we gain any coding simplicity overall with this tuned as our base
> assumption?
>

Yes.

> * Does IE 9+ work on machines without SSE2? [if not too hard to gather
> info for]
>

Yes.

> * Does us doing this on desktop builds have *any* affect on our Mobile
> story?
>

No.

- Kyle

[Mike Hommey]

On Sun, Dec 25, 2011 at 09:20:33PM -0500, Kyle Huey wrote:
> On Sun, Dec 25, 2011 at 9:10 PM, Justin Wood (Callek) <Cal...@gmail.com>wrote:
>

> > Boris Zbarsky wrote:
> >
> >> The bigger question is whether we're ok shipping the subpar JIT-less
> >> browsing experience to people.
> >>
> >
> > Few Questions to help "us" infer this decision line:
> >
> > * What happens when a user tries to launch our "assume SSE2" builds when
> > they don't have a machine that supports SSE2 (both linux and win?)
> >
>

> We'd put in a check and abort at startup that pops up a dialog or something.

(hoping that the compiler won't generate SSE2 code before that popup)

> > * Do we have a method to identify if a user has SSE2 prior to the update?
> >
>

> Not currently.

>
>
> > ** If not now, is it possible to design a way without much overhead that
> > we can pass on to the update server?
> >
>

> Yes.

>
>
> > * Do we gain any coding simplicity overall with this tuned as our base
> > assumption?
> >
>

> Yes.

Overall, no, since we need the same complexity for NEON on ARM.

> > * Does IE 9+ work on machines without SSE2? [if not too hard to gather
> > info for]
> >
>

> Yes.

>
>
> > * Does us doing this on desktop builds have *any* affect on our Mobile
> > story?
> >
>

> No.
>
> - Kyle

[Kyle Huey]

On Mon, Dec 26, 2011 at 2:54 AM, Mike Hommey <m...@glandium.org> wrote:

> On Sun, Dec 25, 2011 at 09:20:33PM -0500, Kyle Huey wrote:
> > On Sun, Dec 25, 2011 at 9:10 PM, Justin Wood (Callek) <Cal...@gmail.com
> >wrote:
> >

> > > Boris Zbarsky wrote:
> > >
> > >> The bigger question is whether we're ok shipping the subpar JIT-less
> > >> browsing experience to people.
> > >>
> > >
> > > Few Questions to help "us" infer this decision line:
> > >
> > > * What happens when a user tries to launch our "assume SSE2" builds
> when
> > > they don't have a machine that supports SSE2 (both linux and win?)
> > >
> >

> > We'd put in a check and abort at startup that pops up a dialog or
> something.
>
> (hoping that the compiler won't generate SSE2 code before that popup)
>

I don't think we'd have to hope, just compile the executable without -msse2
and run the check before loading our shared libs.

- Kyle

[Robert O'Callahan]

On Sun, Dec 25, 2011 at 7:13 AM, Boris Zbarsky <bzba...@mit.edu> wrote:

> For comparison, I believe that Chrome does in fact assume that SSE2 is
> available at runtime. See <
> http://code.google.com/p/chromium/issues/detail?id=9007>. I'm not sure
> about other UAs.
>

Comments in that bug suggest that Chrome does actually work on machines
without SSE2.

Rob
--
"If we claim to be without sin, we deceive ourselves and the truth is not
in us. If we confess our sins, he is faithful and just and will forgive us
our sins and purify us from all unrighteousness. If we claim we have not
sinned, we make him out to be a liar and his word is not in us." [1 John
1:8-10]

[Ehsan Akhgari]

On Sun, Dec 25, 2011 at 4:24 PM, Boris Zbarsky <bzba...@mit.edu> wrote:

> On 12/24/11 1:38 PM, Boris Zbarsky wrote:
>
>> On 12/24/11 1:25 PM, Justin Lebar wrote:
>>
>>> Can we quantify the performance improvement of compiling with -msse2?
>>>
>>
>> At the very least we can do some try pushes, right? I'm glad to do that
>> if someone tells me how to trigger that mode on Windows.
>>
>
> OK, so we have:
>

> No SSE2: https://tbpl.mozilla.org/?**tree=Try&rev=08e1a5a6afc0<https://tbpl.mozilla.org/?tree=Try&rev=08e1a5a6afc0>
> SSE2: https://tbpl.mozilla.org/?tree=Try&rev=4f81468ed6a5
>

FWIW, I think you should also add /G7 when compiling with /arch:SSE2, since
the latter does not imply the former, IINM.

--
Ehsan
<http://ehsanakhgari.org/>

[Boris Zbarsky]

On 12/28/11 1:43 PM, Ehsan Akhgari wrote:
> FWIW, I think you should also add /G7 when compiling with /arch:SSE2, since
> the latter does not imply the former, IINM.

http://msdn.microsoft.com/en-us/library/h4bcz65t%28v=vs.80%29.aspx seems
to claim that /G7 doesn't work with VS2005.

-Boris

[Ehsan Akhgari]

You are right, I was looking at the wrong version on the MSDN page.

--
Ehsan
<http://ehsanakhgari.org/>

[Jean-Marc Desperrier]

djc...@gmail.com a écrit :

> What percentage of users currently don't have SSE2 support? I believe
> it's possible to estimate this from the CPU information in crash
> reports?

Has been done before https://bugzilla.mozilla.org/show_bug.cgi?id=593117
and https://bugzilla.mozilla.org/show_bug.cgi?id=594160
So in september 2009, it was almost 7% of crashes.

According to https://bugzilla.mozilla.org/show_bug.cgi?id=594160#c6 ,
the Raw Dump tab on crash-stats.mozilla.com shows the needed
information, you need to sort out from the info on the second line CPU
maker, family, model, and stepping information whether SSE2 is there or
not (With a little search, I can find that info again, bug 593117 gives
a formula that's correct for most of the cases).

Either there's a way to automatize extracting that info from crash-stats
without generating too much load on it, or someone should run the
request again directly againt the database.

[Robert Kaiser]

Jean-Marc Desperrier schrieb:

> According to https://bugzilla.mozilla.org/show_bug.cgi?id=594160#c6 ,
> the Raw Dump tab on crash-stats.mozilla.com shows the needed
> information, you need to sort out from the info on the second line CPU
> maker, family, model, and stepping information whether SSE2 is there or
> not (With a little search, I can find that info again, bug 593117 gives
> a formula that's correct for most of the cases).

https://crash-analysis.mozilla.com/crash_analysis/ holds
*-pub-crashdata.csv.gz files that have that info from all Firefox
desktop/mobile crashes on a given day, you should be able to analyze
that for this info - with a bias, of course, as it's only people having
crashes that you see there. No idea if the less biased telemetry samples
have that info as well.

Robert Kaiser

[Henri Sivonen]

On Sat, Dec 24, 2011 at 8:13 PM, Boris Zbarsky <bzba...@mit.edu> wrote:
> Summary: we could get some performance benefits by compiling with the
> assumption that the hardware we run on has SSE2 support.  The only drawback
> is that this is false for some middling-old AMD hardware.
>
> Additional information since last time:
>
> 1)  We definitely know we have users on such hardware: see
> https://bugzilla.mozilla.org/show_bug.cgi?id=712261

That bug is about Firefox on Linux, which makes me wonder: Firefox is
the default browser on a number of Linux distros. Are those distros
ready to drop support for CPUs that don't have SSE2 support? (My guess
is no.) It would be unfortunate to lose our placement as the default
browser on Linux distros and it would be unfortunate for Mozilla
Corporation builds and distro builds to diverge (in a way that'd
require the codebase still to support non-SSE2 compilation anyway).

> 2)  As that bug points out, such users no longer have a JS JIT at all as of
> Firefox 9, and have had a semi-crippled one since Firefox 4 (Tracemonkey did
> not require SSE2, but JaegerMonkey does).
>
> So at this point these users are getting a terrible user experience from us
> anyway.  :(

To me, it seems odd to fix the terrible user experience by withdrawing
Firefox from the users in question--especially when right now the
problem is with the JIT and JITs have the advantage that they could
(with engineering effort) vary their output based on the CPU
capabilities.

--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/

[Mounir Lamouri]

On 01/03/2012 08:15 AM, Henri Sivonen wrote:
> On Sat, Dec 24, 2011 at 8:13 PM, Boris Zbarsky<bzba...@mit.edu> wrote:

>> Summary: we could get some performance benefits by compiling with the
>> assumption that the hardware we run on has SSE2 support. The only drawback
>> is that this is false for some middling-old AMD hardware.
>>
>> Additional information since last time:
>>
>> 1) We definitely know we have users on such hardware: see
>> https://bugzilla.mozilla.org/show_bug.cgi?id=712261
>

> That bug is about Firefox on Linux, which makes me wonder: Firefox is
> the default browser on a number of Linux distros. Are those distros
> ready to drop support for CPUs that don't have SSE2 support? (My guess
> is no.) It would be unfortunate to lose our placement as the default
> browser on Linux distros and it would be unfortunate for Mozilla
> Corporation builds and distro builds to diverge (in a way that'd
> require the codebase still to support non-SSE2 compilation anyway).

Would a --enable-sse2 compilation flag be hard to maintain?

--
Mounir

[Benoit Jacob]

2012/1/3 Henri Sivonen <hsiv...@iki.fi>:

> That bug is about Firefox on Linux, which makes me wonder: Firefox is
> the default browser on a number of Linux distros. Are those distros
> ready to drop support for CPUs that don't have SSE2 support? (My guess
> is no.) It would be unfortunate to lose our placement as the default
> browser on Linux distros and it would be unfortunate for Mozilla
> Corporation builds and distro builds to diverge (in a way that'd
> require the codebase still to support non-SSE2 compilation anyway).

Notice that SSE2 is always present on x86-64, and that in the Linux
world, x86-64 is widely used and 32bit x86 support is advertised by
several distros as only for old machines.

So maybe this concern could be alleviated by treating linux separately
from windows. Keep 32bit firefox/linux builds unchanged, promote 64bit
firefox/linux builds to officially supported status (which we need to
do anyway, especially as that's what many distros ship anyway).

Benoit

>
>> 2)  As that bug points out, such users no longer have a JS JIT at all as of
>> Firefox 9, and have had a semi-crippled one since Firefox 4 (Tracemonkey did
>> not require SSE2, but JaegerMonkey does).
>>
>> So at this point these users are getting a terrible user experience from us
>> anyway.  :(
>

> To me, it seems odd to fix the terrible user experience by withdrawing
> Firefox from the users in question--especially when right now the
> problem is with the JIT and JITs have the advantage that they could
> (with engineering effort) vary their output based on the CPU
> capabilities.
>
> --
> Henri Sivonen
> hsiv...@iki.fi
> http://hsivonen.iki.fi/

[Benoit Jacob]

2012/1/2 Robert Kaiser <ka...@kairo.at>:

On yesterday's crash data, assuming that AuthenticAMD\ family\
[1-6][^0-9] is the proper way to identify these old AMD CPUs (I
didn't check that very well), I get these results:

bjacob@cahouette:~$ grep AuthenticAMD\ family\ [1-6][^0-9]
20120102-pub-crashdata.csv | wc -l
10210
bjacob@cahouette:~$ wc -l 20120102-pub-crashdata.csv
324425 20120102-pub-crashdata.csv

This means that out of 324425 crash reports we received, 10210 were on
such CPUs. 10210 / 324425 = 0.031, so the result is that the
proportion of crashes from users of these old AMD CPUs is 3.1%.

Benoit

>
> Robert Kaiser

[Benoit Jacob]

2012/1/3 Benoit Jacob <jacob.b...@gmail.com>:
> 2012/1/2 Robert Kaiser <ka...@kairo.at>:

> On yesterday's crash data, assuming that AuthenticAMD\ family\
> [1-6][^0-9]  is the proper way to identify these old AMD CPUs (I
> didn't check that very well), I get these results:
>
> bjacob@cahouette:~$ grep AuthenticAMD\ family\ [1-6][^0-9]
> 20120102-pub-crashdata.csv | wc -l
> 10210
> bjacob@cahouette:~$ wc -l 20120102-pub-crashdata.csv
> 324425 20120102-pub-crashdata.csv
>
> This means that out of 324425 crash reports we received, 10210 were on
> such CPUs. 10210 / 324425 = 0.031, so the result is that the
> proportion of crashes from users of these old AMD CPUs is 3.1%.
>
> Benoit

One would also have to account for non-SSE2-capable Intel CPUs, but I
don't know how to identify them. GenuineIntel family 6 seems to
contain both Pentium III (non SSE2 capable) and Pentium M (SSE2
capable) so we'd have to look at the model number.

[Jeff Muizelaar]

On 2012-01-03, at 2:01 PM, Benoit Jacob wrote:

> 2012/1/2 Robert Kaiser <ka...@kairo.at>:

> On yesterday's crash data, assuming that AuthenticAMD\ family\
> [1-6][^0-9] is the proper way to identify these old AMD CPUs (I
> didn't check that very well), I get these results:

The measurement I have used in the past was:

CPUs have sse2 if:

if vendor == AuthenticAMD and family >= 15
if vendor == GenuineIntel and family >= 15 or (family == 6 and (model == 9 or model > 11))
if vendor == CentaurHauls and family >= 6 and model >= 10

[Benoit Jacob]

2012/1/3 Jeff Muizelaar <jmuiz...@mozilla.com>:

>
> On 2012-01-03, at 2:01 PM, Benoit Jacob wrote:
>
> 2012/1/2 Robert Kaiser <ka...@kairo.at>:
>

> On yesterday's crash data, assuming that AuthenticAMD\ family\
> [1-6][^0-9]  is the proper way to identify these old AMD CPUs (I
> didn't check that very well), I get these results:
>
>
> The measurement I have used in the past was:
>
> CPUs have sse2 if:
>
> if vendor == AuthenticAMD and family >= 15
> if vendor == GenuineIntel and family >= 15 or (family == 6 and (model == 9
> or model > 11))
> if vendor == CentaurHauls and family >= 6 and model >= 10
>

Thanks.

AMD and Intel CPUs amount to 296362 crashes:

bjacob@cahouette:~$ egrep AuthenticAMD\|GenuineIntel
20120102-pub-crashdata.csv | wc -l
296362

Counting SSE2-capable CPUs:

bjacob@cahouette:~$ egrep GenuineIntel\ family\ 1[5-9]
20120102-pub-crashdata.csv | wc -l
58490
bjacob@cahouette:~$ egrep GenuineIntel\ family\ [2-9][0-9]
20120102-pub-crashdata.csv | wc -l
0
bjacob@cahouette:~$ egrep GenuineIntel\ family\ 6\ model\ 9
20120102-pub-crashdata.csv | wc -l
792
bjacob@cahouette:~$ egrep GenuineIntel\ family\ 6\ model\ 1[2-9]
20120102-pub-crashdata.csv | wc -l
52473
bjacob@cahouette:~$ egrep GenuineIntel\ family\ 6\ model\ [2-9][0-9]
20120102-pub-crashdata.csv | wc -l
103655
bjacob@cahouette:~$ egrep AuthenticAMD\ family\ 1[5-9]
20120102-pub-crashdata.csv | wc -l
59463
bjacob@cahouette:~$ egrep AuthenticAMD\ family\ [2-9][0-9]
20120102-pub-crashdata.csv | wc -l
8120

Total SSE2 capable CPUs:

58490 + 792 + 52473 + 103655 + 59463 + 8120 = 282993

1 - 282993 / 296362 = 0.045

So the proportion of non-SSE2-capable CPUs among crash reports is 4.5 %.

Benoit

[Benoit Jacob]

2012/1/3 Benoit Jacob <jacob.b...@gmail.com>:

> So the proportion of non-SSE2-capable CPUs among crash reports is 4.5 %.

Also, CentaurHauls doesn't make a significant difference (0.1%
prevalence, 20% of which is not SSE2 capable); and the above figure
seems to be Windows-specific as Mac and Linux use different names for
CPU vendors (e.g. amd64 vs AuthenticAMD).

Benoit

[Boris Zbarsky]

On 1/3/12 2:15 AM, Henri Sivonen wrote:
> To me, it seems odd to fix the terrible user experience by withdrawing
> Firefox from the users in question--especially when right now the
> problem is with the JIT and JITs have the advantage that they could
> (with engineering effort) vary their output based on the CPU
> capabilities.

Note that we _may_ be able to just do floating point ops as stubcalls
instead of jit instructions on non-SSE2 hardware once the infrastructure
for doing that sort of thing for ARM softfloat lands.

At which point non-SSE2 intel chips would have a jit again, albeit one
that's slow on floating point ops.

-Boris

[matthe...@gmail.com]

Just for the record, I coded this analysis up here: https://gist.github.com/matthew-brett/9cb5274f7451a3eb8fc0

SSE2 apparently now at about one percent:

20120102-pub-crashdata.csv.gz: 4.53
20120401-pub-crashdata.csv.gz: 4.24
20120701-pub-crashdata.csv.gz: 2.77
20121001-pub-crashdata.csv.gz: 2.83
20130101-pub-crashdata.csv.gz: 2.66
20130401-pub-crashdata.csv.gz: 2.59
20130701-pub-crashdata.csv.gz: 2.20
20131001-pub-crashdata.csv.gz: 1.92
20140101-pub-crashdata.csv.gz: 1.86
20140401-pub-crashdata.csv.gz: 1.12

Cheers,

Matthew

[Benoit Jacob]

Wonderful, thanks Matthew!

@Stability-team: ^^^ see the value of public crashdata CSV files in action!
Thanks!

Benoit

[Jonas Sicking]

I'm curious how much of that 1% is on old versions of Firefox and
aren't updating anyway?

/ Jonas

[Matthew Brett]

Hi,

On Thu, May 8, 2014 at 6:08 PM, Jonas Sicking <jo...@sicking.cc> wrote:
> I'm curious how much of that 1% is on old versions of Firefox and
> aren't updating anyway?
>
> / Jonas
>
> On Thu, May 8, 2014 at 5:42 PM, <matthe...@gmail.com> wrote:

For April, it looks like these are mostly modern versions.

I took out all the no-SSE2 entries and analyzed them.

Here are the most common version numbers with percentages (of all
non-SSE2 entries):

28. , 60.1
27. , 7.3
29. , 7.1
12. , 2.1
10. , 1.3
3.6, 1.3
11. , 1.2
3.6, 1.2
26. , 1.1

Cheers,

Matthew

[Chris Peterson]

What does requiring SSE2 buy us? 1% of hundreds of millions of Firefox
users is still millions of people.

chris

[Benoit Jacob]

Totally agree that 1% is probably still too much to drop, but the 4x drop
over the past two years makes me hopeful that we'll be able to drop
non-SSE2, eventually.

SSE2 is not just about SIMD. The most important thing it buys us IMHO is to
be able to not use x87 instructions anymore and instead use SSE2 (scalar)
instructions. That removes entire classes of bugs caused by x87 being
non-IEEE754-compliant with its crazy 80-bit registers.

Benoit

[Chris Peterson]

Which Firefox platforms must support x86 without SSE2? Just Win32 and Linux?


chris

[Bobby Holley]

Can somebody get us less-circumstantial evidence that the stuff from
http://www.palemoon.org/technical.shtml#speed , which AFAICT are the only
perf numbers that have been cited in this thread?

On Fri, May 9, 2014 at 10:14 AM, Benoit Jacob <jacob.b...@gmail.com>wrote:

> Totally agree that 1% is probably still too much to drop, but the 4x drop
> over the past two years makes me hopeful that we'll be able to drop
> non-SSE2, eventually.
>
> SSE2 is not just about SIMD. The most important thing it buys us IMHO is to
> be able to not use x87 instructions anymore and instead use SSE2 (scalar)
> instructions. That removes entire classes of bugs caused by x87 being
> non-IEEE754-compliant with its crazy 80-bit registers.
>
> Benoit
>
>
> 2014-05-09 13:01 GMT-04:00 Chris Peterson <cpet...@mozilla.com>:
>

[Benoit Jacob]

Again (see my previous email) I dont think that performance is the primary
factor here. I care more about not having to worry about two different
flavors of floating point semantics.

Just 2 days ago a colleague had a clever implementation of something he
needed to do in gecko gfx code, and had to back out from that because it
would give the wrong result on x87. I don't know how many other things we
already do, that silently fail on x87 without us realizing. That's what I
worry about.

Benoit

2014-05-09 13:19 GMT-04:00 Bobby Holley <bobby...@gmail.com>:

> Can somebody get us less-circumstantial evidence that the stuff from
> http://www.palemoon.org/technical.shtml#speed , which AFAICT are the only
> perf numbers that have been cited in this thread?
>
>
> On Fri, May 9, 2014 at 10:14 AM, Benoit Jacob <jacob.b...@gmail.com>wrote:
>
>> Totally agree that 1% is probably still too much to drop, but the 4x drop
>> over the past two years makes me hopeful that we'll be able to drop
>> non-SSE2, eventually.
>>
>> SSE2 is not just about SIMD. The most important thing it buys us IMHO is
>> to
>> be able to not use x87 instructions anymore and instead use SSE2 (scalar)
>> instructions. That removes entire classes of bugs caused by x87 being
>> non-IEEE754-compliant with its crazy 80-bit registers.
>>
>> Benoit
>>
>>
>> 2014-05-09 13:01 GMT-04:00 Chris Peterson <cpet...@mozilla.com>:
>>

[Rik Cabanier]

On Fri, May 9, 2014 at 10:14 AM, Benoit Jacob <jacob.b...@gmail.com>wrote:

> Totally agree that 1% is probably still too much to drop, but the 4x drop
> over the past two years makes me hopeful that we'll be able to drop
> non-SSE2, eventually.
>
> SSE2 is not just about SIMD. The most important thing it buys us IMHO is to
> be able to not use x87 instructions anymore and instead use SSE2 (scalar)
> instructions. That removes entire classes of bugs caused by x87 being
> non-IEEE754-compliant with its crazy 80-bit registers.
>

Out of interest, do you have links to bugs for this issue?

Also, can't you ask the compiler to produce both sse and non-sse code and
make a decision at runtime?

> 2014-05-09 13:01 GMT-04:00 Chris Peterson <cpet...@mozilla.com>:
>

[Benoit Jacob]

2014-05-09 13:24 GMT-04:00 Rik Cabanier <caba...@gmail.com>:

>
>
>
> On Fri, May 9, 2014 at 10:14 AM, Benoit Jacob <jacob.b...@gmail.com>wrote:
>
>> Totally agree that 1% is probably still too much to drop, but the 4x drop
>> over the past two years makes me hopeful that we'll be able to drop
>> non-SSE2, eventually.
>>
>> SSE2 is not just about SIMD. The most important thing it buys us IMHO is
>> to
>> be able to not use x87 instructions anymore and instead use SSE2 (scalar)
>> instructions. That removes entire classes of bugs caused by x87 being
>> non-IEEE754-compliant with its crazy 80-bit registers.
>>
>
> Out of interest, do you have links to bugs for this issue?
>

No: there are the bugs we probably have but don't know about; and there are
the things that we caught in time and caused us to give up on approaches
before they would become patches... I don't have an example of a bug we
found after the fact.

>
> Also, can't you ask the compiler to produce both sse and non-sse code and
> make a decision at runtime?
>

Not that I know of. At least GCC documentation does no list anything about
that here, http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86-64-Options.html

-mfpmath=both or -mfpmath=sse+387 does not seem to be doing that; instead
it seems to be about using both in the same code path.

Benoit

>
>
>> 2014-05-09 13:01 GMT-04:00 Chris Peterson <cpet...@mozilla.com>:
>>

[Trevor Saunders]

> >
> > Also, can't you ask the compiler to produce both sse and non-sse code and
> > make a decision at runtime?
> >
>
> Not that I know of. At least GCC documentation does no list anything about
> that here, http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86-64-Options.html
>
> -mfpmath=both or -mfpmath=sse+387 does not seem to be doing that; instead
> it seems to be about using both in the same code path.

in an ideal world we could use __attribute__((target("whatever"))) but
we'd need a newer gcc, and only gcc supports that atm afaik. What we've
done in other places where using ssee2 is a big win is to add a second
file that we compile with -msse2 and then we do some runtime detection
(mozilla/SSE.h) and then we only call into the file compiled with
-mssse2 if the runtime detection says we have sse.

Trev

>
> Benoit
>
>
> >
> >
> >> 2014-05-09 13:01 GMT-04:00 Chris Peterson <cpet...@mozilla.com>:
> >>

[Gary Kwong]

On 5/9/14, 10:24 AM, Rik Cabanier wrote:
> Out of interest, do you have links to bugs for this issue?

SpiderMonkey has one here:

https://bugzilla.mozilla.org/show_bug.cgi?id=948321
(Differential Testing: Different division results on x86 platforms)

and further differential testing on Win32 is blocked by:

https://bugzilla.mozilla.org/show_bug.cgi?id=998577
Unable to compile js shells on Windows with /arch:SSE2 on MSVC2010


-Gary

[Robert Kaiser]

When you want to whole stability group to get a message, please send to
stability@m.o ;-)

That said, IMHO, the API, esp. the "SuperSearch" part of it, should be
just as good or even better than the CSV stuff you're doing, as you
should be able to more directly get a lot of what you need out of there.
AFAIK you were pointed to that for B2G stuff already anyhow (as the CSVs
only contain Firefox and Firefox for Android).

KaiRo


Benoit Jacob schrieb: