Granular benchmarks of palette transformations.

[anforowicz]

No description provided.

[anforowicz]

@fintelia, can you PTAL?

• I think it may be best to avoid squeezing the commits when merging - I think it is desirable to preserve individual commits

• Memoization in the-4th-commit-in-the-PR-under-review seems to result in a positive performance change in general except 2 benchmarks that operate on generated inputs. I think this shouldn’t block merging of this PR: 1) the regressions are minor (same or smaller in size than improvements in other benchmarks), 2) improvements on real-world inputs should probably outweigh the regressions on (some) generated inputs, 3) I don’t understand why memoization would help most benchmarks except these two and therefore I am sheepishly leaning toward dismissing them as something outlandish like memory layout.

• Once/if this PR gets merged, I want to try working on the following series of commits (not sure how to split them across PRs + if all performance improvement ideas will bear fruit):

  • Next PR: Initial memoization for palette transformation

    • Commit A: separate transform/palette.rs module (also move unit tests)
    • Commit B: fn => Box<dyn Fn> (end-to-end perf impact via extra allocation + dyn; other commits will only impact paletted images)
    • Commit C: simple memoization
      • Introduce create_rgba_palette(plte, trns) -> [[u8;4]; 256] - single loop over plte [with trns lookup with fallback to 0xFF] - this should be easier to SIMD-ify later (I think…)
      • Add pallette.rs/mod-level comment: 1) link to slidedeck by ARM engineers + permalink to code in libpng + link to top500 and QOI corpus where there are ~35% of paletted images, 2) “Break-even point” section with TODOs to measure the cut-off of when the old is faster than new (and outline of how this can be measured / calculate)
      • The prod code (when compiled in test [and/or debug?] config) should compare that all versions of functions return the same result: expansion: 1) old (non-memoized) VS new (memoized) VS (future new/SIMD), 2) create_rgba_palette: regular VS (future SIMD)

  • Other PRs:

    • Commit D: create_rgba_palette - read 4-bytes-at-a-time from plte
    • Commit E: std::simd - create_rgba_palette?
    • Commit F: std::simd - expand_palette? Only work with 8-bit input (otherwise fall back to non-SIMD). Maybe expand_rgba is already auto-vectorized, but probably expand_rgb will get better with SIMD?
    • Commit G: Fall back to the old, non-memoized code for small inputs?

/cc @Shnatsel