Skip to content

Faster get_block and quantize_block on the scalar path - #39

Merged
vstroebel merged 1 commit into
vstroebel:mainfrom
imurashka:scalar-block-quantize
Oct 25, 2026
Merged

vstroebel merged 1 commit into
vstroebel:mainfrom
imurashka:scalar-block-quantize

Conversation

@imurashka

Copy link
Copy Markdown
Contributor

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.

@vstroebel
vstroebel merged commit 3849e2b into vstroebel:main Oct 25, 2026
7 checks passed
@imurashka
imurashka deleted the scalar-block-quantize branch October 29, 2026 13:34
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.

2 participants