Improve Blending BlitRow functions on x86 by around 10% by making better use of SSE2

Improve Blending BlitRow functions on x86 by around 10% by making better use of SSE2
instructions.
The optimizations done in this patch are:
- Use __mm_mulhi_epi16 instead of __mm_mullo_epi16 for scale
  multiplication to avoid the need to do the division (or shift).
- Take into account the Atom micro-architecture (execution ports)
  constraints and interleave the operations to make better (parallel)
  use of two execution ports.

Using:
bench -config 8888 -forceBlend 1 -match bitmap_8888 -repeat 100
(a benchmark with most cycles going in S32A_Blend_BlitRow32_SSE2 and S32_Blend_BlitRow32_SSE2), we get on a z600 64 bit:
running bench [640 480]           bitmap_8888_update  8888: cmsecs =   5.60
running bench [640 480]  bitmap_8888_update_volatile  8888: cmsecs =   5.61
running bench [640 480]                  bitmap_8888  8888: cmsecs =   5.59
running bench [640 480]                bitmap_8888_A  8888: cmsecs =   6.98

after:
running bench [640 480]           bitmap_8888_update  8888: cmsecs =   5.15
running bench [640 480]  bitmap_8888_update_volatile  8888: cmsecs =   5.05
running bench [640 480]                  bitmap_8888  8888: cmsecs =   5.03
running bench [640 480]                bitmap_8888_A  8888: cmsecs =   6.30

or between 8 and 11 % on a 64 bit Z600. on a 32 bit Atom, the results are between 4 and 10%
faster.

Credits: Tom C at Intel and lcwu

[TomH, 2012-02-06 20:30:25]

Code changes LGTM, and I can see the expected performance improvement on a Z600.
Higher-level issues:

I assume that interleaving for Atom isn't expected to hurt our performance on
other processors?

I'm a little worried when I see improvements as low as 4%, because we can have
more noise than that on the benchmarks.
(Rule of thumb: on Linux, -repeat 50 can have 10% variation in subsequent runs,
-repeat 150 usually 1%.)

[evannier, 2012-02-06 22:09:31]

On 2012/02/06 20:30:25, TomH wrote:
> Code changes LGTM, and I can see the expected performance improvement on a
Z600.
> Higher-level issues:
> 
> I assume that interleaving for Atom isn't expected to hurt our performance on
> other processors?
I have not seen any indication of this.
Note as detailed in the comment, this is really to work around a problem the gcc
we used (4.5.2 or derivative if I remember correctly) that was not doing
scheduling properly for atom, and causing stalls.
With a properly written scheduler, the compiler/scheduler would reorder anyway
the code the proper way. The actual speed up was though tiny but measurable.
(CC'ing here lcwu, the main author of the changes who investigated the actual
scheduling issue, and who would be able to give actual numbers there).

> 
> I'm a little worried when I see improvements as low as 4%, because we can have
> more noise than that on the benchmarks.
> (Rule of thumb: on Linux, -repeat 50 can have 10% variation in subsequent
runs,
> -repeat 150 usually 1%.)

Valid concern. I have run these through various methods, including micro
benchmarks to back up the actual data, and did the experiments multiple times to
make sure there was no real variations in the the measurements. I have used
-repeat 100 (as I had found that the default did not give good enough
precision).
With 100, I have not found the large error rate in the measurement you are
talking about: numbers seem to be fairly constant with slight variations on the
3rd digit (+-1), so for an error of less than a percent in the measurement.

Let me know if there is additional tests, additional data you want to collect,
code modifications you would like to see.

Thanks !

[TomH, 2012-02-07 14:29:59]

On 2012/02/06 22:09:31, evannier wrote:
> Let me know if there is additional tests, additional data you want to collect,
> code modifications you would like to see.

On 2012/02/06 22:09:31, evannier wrote:
> Let me know if there is additional tests, additional data you want to collect,
> code modifications you would like to see.

Nope, I'm content with your answers. Do you want to land this in Skia, or shall
I shepherd it through?

[evannier, 2012-02-10 21:36:53]

On 2012/02/07 14:29:59, TomH wrote:
> On 2012/02/06 22:09:31, evannier wrote:
> > Let me know if there is additional tests, additional data you want to
collect,
> > code modifications you would like to see.
> 
> On 2012/02/06 22:09:31, evannier wrote:
> > Let me know if there is additional tests, additional data you want to
collect,
> > code modifications you would like to see.
> 
> Nope, I'm content with your answers. Do you want to land this in Skia, or
shall
> I shepherd it through?

I just uploaded a new version with a some more comments, otherwise the code is
identical.

as said over chat, since I do not have commit access, feel free to check this in
whenever you get a chance.

Thanks !

[TomH, 2012-02-28 16:17:19]

This one almost slipped through the cracks - committed as r3273.
Thanks again!
Please close the issue when you have a moment.