Double AdobeCMYK_to_sRGB speed with faster rounding

Double AdobeCMYK_to_sRGB speed with faster rounding

FXSYS_round is painfully slow on Windows. It does range checking and
then calls an extremely expensive function. It ends up consuming half
the CPU time when decoding the images in PDFs such as this one:

    https://www.ets.org/Media/Tests/GRE/pdf/gre_research_validity_data.pdf

SSE can be used to optimize this:

  __m128 cmyk = {c * 255, m * 255, y * 255, k * 255};
  uint32_t output[4];
  _mm_storeu_si128((__m128i*)output, _mm_cvtps_epi32(cmyk));

but is cryptic, only works for x86/x64, and gives basically identical
performance to this solution - int(c * 255 + 0.5f);

The rounding behavior is not identical but in practice this rarely
matters, and in this specific case it does not matter because the edge
cases that vary are not hit.

The three divisions at the end were changed to multiplies because
profiling showed they were a significant cost.

This change reduces the image-decode stalls in the PDF listed above by
about 40%, making for a noticeably better experience. Further
optimizations are possible but would require significantly more time and
testing.

BUG=617365
Committed: https://pdfium.googlesource.com/pdfium/+/160bd0e26f5dfe5fa11322f61b3d156c2214cba8

[brucedawson, 2016-06-23 20:47:41]

PTAL

This contains some error checking that can't ship as is - a faked out DCHECK_EQ.
What is the pdfium equivalent?

But otherwise it is good - a nice easy performance improvement. Thoughts?

[dsinclair, 2016-06-23 20:52:32]

dsinclair@chromium.org changed reviewers:
+ caryclark@chromium.org, dsinclair@chromium.org, thestig@chromium.org,
tsepez@chromium.org

[dsinclair, 2016-06-23 20:52:32]

Added a few reviewers to take a look.

PDFium doesn't have DCHECK, we just use ASSERT.

[brucedawson, 2016-06-23 20:59:42]

On 2016/06/23 20:52:32, dsinclair wrote:
> Added a few reviewers to take a look.
> 
> PDFium doesn't have DCHECK, we just use ASSERT.

Updated to use ASSERT()

[Lei Zhang, 2016-06-23 22:34:30]

Description was changed from

==========
Double AdobeCMYK_to_sRGB speed with faster rounding

FXSYS_round is painfully slow on Windows. It does range checking and
then calls an extremely expensive function. It ends up consuming half
the CPU time when decoding the images in PDFs such as this one:

    https://www.ets.org/Media/Tests/GRE/pdf/gre_research_validity_data.pdf

SSE can be used to optimize this:

  __m128 cmyk = {c * 255, m * 255, y * 255, k * 255};
  uint32_t output[4];
  _mm_storeu_si128((__m128i*)output, _mm_cvtps_epi32(cmyk));

but is cryptic, only works for x86/x64, and gives basically identical
performance to this solution - int(c * 255 + 0.5f);

The rounding behavior is not identical but in practice this rarely
matters, and in this specific case it does not matter because the edge
cases that vary are not hit.

The three divisions at the end were changed to multiplies because
profiling showed they were a significant cost.

This change reduces the image-decode stalls in the PDF listed above by
about 40%, making for a noticeably better experience. Further
optimizations are possible but would require significantly more time and
testing.

BUG=617365
==========

to

==========
Double AdobeCMYK_to_sRGB speed with faster rounding

FXSYS_round is painfully slow on Windows. It does range checking and
then calls an extremely expensive function. It ends up consuming half
the CPU time when decoding the images in PDFs such as this one:

    https://www.ets.org/Media/Tests/GRE/pdf/gre_research_validity_data.pdf

SSE can be used to optimize this:

  __m128 cmyk = {c * 255, m * 255, y * 255, k * 255};
  uint32_t output[4];
  _mm_storeu_si128((__m128i*)output, _mm_cvtps_epi32(cmyk));

but is cryptic, only works for x86/x64, and gives basically identical
performance to this solution - int(c * 255 + 0.5f);

The rounding behavior is not identical but in practice this rarely
matters, and in this specific case it does not matter because the edge
cases that vary are not hit.

The three divisions at the end were changed to multiplies because
profiling showed they were a significant cost.

This change reduces the image-decode stalls in the PDF listed above by
about 40%, making for a noticeably better experience. Further
optimizations are possible but would require significantly more time and
testing.

BUG=617365
==========

[Lei Zhang, 2016-06-23 22:34:30]

thestig@chromium.org changed reviewers:
+ caryclark@google.com
- caryclark@chromium.org

[Lei Zhang, 2016-06-23 22:36:11]

Cary's probably the best reviewer?

[caryclark, 2016-06-27 13:11:23]

lgtm

A unit test would be nice.

[dsinclair, 2016-06-27 13:46:13]

The CQ bit was checked by dsinclair@chromium.org

[dsinclair, 2016-06-27 13:46:13]

lgtm

RS lgtm

[commit-bot: I haz the power, 2016-06-27 13:46:23]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-06-27 13:58:43]

Description was changed from

==========
Double AdobeCMYK_to_sRGB speed with faster rounding

FXSYS_round is painfully slow on Windows. It does range checking and
then calls an extremely expensive function. It ends up consuming half
the CPU time when decoding the images in PDFs such as this one:

    https://www.ets.org/Media/Tests/GRE/pdf/gre_research_validity_data.pdf

SSE can be used to optimize this:

  __m128 cmyk = {c * 255, m * 255, y * 255, k * 255};
  uint32_t output[4];
  _mm_storeu_si128((__m128i*)output, _mm_cvtps_epi32(cmyk));

but is cryptic, only works for x86/x64, and gives basically identical
performance to this solution - int(c * 255 + 0.5f);

The rounding behavior is not identical but in practice this rarely
matters, and in this specific case it does not matter because the edge
cases that vary are not hit.

The three divisions at the end were changed to multiplies because
profiling showed they were a significant cost.

This change reduces the image-decode stalls in the PDF listed above by
about 40%, making for a noticeably better experience. Further
optimizations are possible but would require significantly more time and
testing.

BUG=617365
==========

to

==========
Double AdobeCMYK_to_sRGB speed with faster rounding

FXSYS_round is painfully slow on Windows. It does range checking and
then calls an extremely expensive function. It ends up consuming half
the CPU time when decoding the images in PDFs such as this one:

    https://www.ets.org/Media/Tests/GRE/pdf/gre_research_validity_data.pdf

SSE can be used to optimize this:

  __m128 cmyk = {c * 255, m * 255, y * 255, k * 255};
  uint32_t output[4];
  _mm_storeu_si128((__m128i*)output, _mm_cvtps_epi32(cmyk));

but is cryptic, only works for x86/x64, and gives basically identical
performance to this solution - int(c * 255 + 0.5f);

The rounding behavior is not identical but in practice this rarely
matters, and in this specific case it does not matter because the edge
cases that vary are not hit.

The three divisions at the end were changed to multiplies because
profiling showed they were a significant cost.

This change reduces the image-decode stalls in the PDF listed above by
about 40%, making for a noticeably better experience. Further
optimizations are possible but would require significantly more time and
testing.

BUG=617365

Committed:
https://pdfium.googlesource.com/pdfium/+/160bd0e26f5dfe5fa11322f61b3d156c2214...
==========

[commit-bot: I haz the power, 2016-06-27 13:58:44]

Committed patchset #3 (id:40001) as
https://pdfium.googlesource.com/pdfium/+/160bd0e26f5dfe5fa11322f61b3d156c2214...