How much do we care about pre-Nehalem performance?

[Henri Sivonen]

Do I read agner.org correctly that movdqa was obsoleted by Nehalem,
Silvermont and Bulldozer in the sense that movdqu is no worse than
movdqa on those or later microarchitectures?

Do we have numbers of how our installed base is split between earlier
than Nehalem/Silvermont/Bulldozer vs. Nehalem/Silvermont/Bulldozer or
later?

How much do we care about performance on microarchitectures earlier
than Nehalem/Silvermont/Bulldozer? Would we want more readable,
smaller and on Nehalem/Silvermont/Bulldozer or later potentially a bit
faster code in exchange for a perf regression on
pre-Nehalem/Silvermont/Bulldozer microarchitectures?

(Notably, Core 2 Duo / Penryn at least used to be pretty popular and
predates Nehalem.)

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

[Henri Sivonen]

On Tue, Mar 27, 2018 at 1:36 PM, Henri Sivonen <hsiv...@hsivonen.fi> wrote:
> Do I read agner.org correctly that movdqa was obsoleted by Nehalem,
> Silvermont and Bulldozer in the sense that movdqu is no worse than
> movdqa on those or later microarchitectures?

http://www.agner.org/optimize/instruction_tables.pdf for the precise
URL I meant.

[Henri Sivonen]

On Tue, Mar 27, 2018 at 1:36 PM, Henri Sivonen <hsiv...@hsivonen.fi> wrote:

> Do we have numbers of how our installed base is split between earlier
> than Nehalem/Silvermont/Bulldozer vs. Nehalem/Silvermont/Bulldozer or
> later?

Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1449496

I'd appreciate it if a CPUID expert reviewed the query I requested in the bug.

[hsiv...@mozilla.com]

On Saturday, March 31, 2018 at 6:49:25 AM UTC-7, Henri Sivonen wrote:
> On Tue, Mar 27, 2018 at 1:36 PM, Henri Sivonen <hsiv...@hsivonen.fi> wrote:
> > Do we have numbers of how our installed base is split between earlier
> > than Nehalem/Silvermont/Bulldozer vs. Nehalem/Silvermont/Bulldozer or
> > later?
>
> Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1449496

The answer is that our x86/x86_64 release population is 80% fast unaligned SSE2 and 20% slower unaligned SSE2. My conclusion is that I should keep code complexity that caters to the 20% on the most important code paths but that for the less important code paths it's probably OK to do unaligned-only. (encoding_rs does unaligned-only for UTF-16LE/UTF-16BE decode, which isn't used much on the Web, but will retain the alignment check complexity for other stuff.)