Skip to content

util/compression: enable zstd.WithConcurrentBlocks#6936

Draft
thaJeztah wants to merge 2 commits into
moby:masterfrom
thaJeztah:compress_WithConcurrentBlocks
Draft

util/compression: enable zstd.WithConcurrentBlocks#6936
thaJeztah wants to merge 2 commits into
moby:masterfrom
thaJeztah:compress_WithConcurrentBlocks

Conversation

@thaJeztah

Copy link
Copy Markdown
Member

util/compression: enable WithConcurrentBlocks

This option was added in klauspost/compress v0.19; https://pkg.go.dev/github.com/klauspost/[email protected]/zstd#section-readme

Parallel Stream Compression

For maximum throughput on large streams, use WithConcurrentBlocks(true)
together with WithEncoderConcurrency(n) where n is the number of CPU cores
you want to use. This splits the input into large sections (jobs) that are
compressed simultaneously by multiple goroutines, similar to how the C zstd
library does multithreaded compression.

Given that BuildKit creates a new Writer for each blob, we may need
to look what the best value is for WithEncoderConcurrency.

Benchmarks as mentioned in upstream;

Level 1 thread 4 threads 16 threads 1T ratio 16T ratio
fastest 783 MB/s 2950 MB/s (3.8×) 6939 MB/s (8.9×) 12.24% 12.26%
default 728 MB/s 2533 MB/s (3.5×) 5340 MB/s (7.3×) 10.67% 10.68%
better 434 MB/s 1105 MB/s (2.5×) 2206 MB/s (5.1×) 9.14% 9.21%
best 129 MB/s 367 MB/s (2.8×) 884 MB/s (6.8×) 8.48% 8.63%

…vels

The toZstdEncoderLevel utility was introduced in cab33b1,
and has a custom mapping of zstd compressions levels to their go (klauspost/compress)
counterparts.

Swap our local implementation for the one in klauspost/compress so that new levels
implemented in klauspost/compress will also be mapped if they arrive.

This does change some mappings;

| Input level | Before                 | After                    |
|-------------|------------------------|--------------------------|
| `< 0`       | `SpeedDefault`         | `SpeedFastest`           |
| `6`         | `SpeedDefault`         | `SpeedBetterCompression` |
| `9`         | `SpeedBestCompression` | `SpeedBetterCompression` |

While updating, also slightly refactor;

- use an options slice to skip setting the option if no config was set, and
  to allow adding additional options.
- inline zstdWriter where used, as it was only used in a single place.

Signed-off-by: Sebastiaan van Stijn <[email protected]>
@thaJeztah thaJeztah changed the title Compress with concurrent blocks util/compression: enable WithConcurrentBlocks Jul 7, 2026
This option was added in klauspost/compress v0.19;

> Parallel Stream Compression
>
> For maximum throughput on large streams, use WithConcurrentBlocks(true)
> together with WithEncoderConcurrency(n) where n is the number of CPU cores
> you want to use. This splits the input into large sections (jobs) that are
> compressed simultaneously by multiple goroutines, similar to how the C zstd
> library does multithreaded compression.

Given that BuildKit creates a new Writer for each blob, we may need
to look what the best value is for WithEncoderConcurrency.

Signed-off-by: Sebastiaan van Stijn <[email protected]>
@thaJeztah thaJeztah force-pushed the compress_WithConcurrentBlocks branch from eddc195 to b161b5c Compare July 7, 2026 17:56
@thaJeztah thaJeztah changed the title util/compression: enable WithConcurrentBlocks util/compression: enable zstd.WithConcurrentBlocks Jul 7, 2026
Comment thread util/compression/zstd.go
return func(dest io.Writer, _ string) (io.WriteCloser, error) {
return zstdWriter(comp)(dest)
opts := []zstd.EOption{
zstd.WithEncoderConcurrency(runtime.GOMAXPROCS(0)), // TBD: default is GOMAXPROCS for each writer.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure what the best value is to use here; effectively this is explicitly setting the default.

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

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant