Skip to content

Faster get_block and quantize_block on the scalar path - #39

Open
imurashka wants to merge 1 commit into
vstroebel:mainfrom
imurashka:scalar-block-quantize
Open

imurashka wants to merge 1 commit into
vstroebel:mainfrom
imurashka:scalar-block-quantize

Conversation

@imurashka

Copy link
Copy Markdown

Two small changes in encoder.rs, the output bytes stay the same:

  • get_block: when there is no subsampling (both strides are 1) it copies each row of 8 pixels from a slice, without the index math and bounds check per pixel.
  • quantize_block: quantizes in natural order first and then reorders to zig-zag, so the quantize loop can be vectorized.

The criterion encode bench on an Apple M4 Pro, main vs this branch:

bench main this branch change
encode rgb 100 46.30 ms 44.68 ms -3.5%
encode rgb 4x1 24.64 ms 23.88 ms -2.9%
encode rgb progressive 25.38 ms 24.57 ms -3.1%
encode rgb optimized 115.0 ms 99.8 ms -13.2%
encode rgb optimized progressive 105.2 ms 101.0 ms -4.0%
encode rgb mixed 202.8 ms 194.4 ms -4.1%

With 4:4:4 sampling the gain is bigger, because every plane takes the new path: on x86-64 a 1200x630 RGBA image at quality 82 went from 6.29 ms to 5.57 ms. I checked the output is byte-identical there, with 4:4:4 and 4:2:0. cargo test, cargo fmt --check and clippy pass.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant