release: v10.14.0 — JP3D parallel per-slice encode#450
Merged
Conversation
The first JP3D encoder speedup of the v10 arc. JP3DSliceStackCodec's
per-slice 2D encode loop was sequential since shipping; v10.14.0
splits it into sequential slices 0-1 (commits the M6/M7 Z-delta
tile-mode decision) + parallel slices 2..N via TaskGroup.
JP3D encode wins (M2 release, --jp3d bench, in-process, 7 runs / 2 warmups, median):
Fixture vx enc ser enc par Δ ms ratio
----------------------------------------------------------------
mr_3d_small 262K 11.84 7.58 −4.27 1.56x
ct_3d_small 1.05M 33.92 26.17 −7.75 1.30x
us_3d_small 1.84M 58.58 40.73 −17.85 1.44x
mr_3d_mid 2.10M 71.59 65.68 −5.91 1.09x
ct_3d_mid 8.39M 295.58 246.98 −48.60 1.20x
ct_3d_large 16.78M 615.94 539.95 −75.99 1.14x
All 6/6 fixtures clear the 3 ms acceptance threshold. Smallest
fixture shows the largest relative speedup (1.56× on mr_3d_small)
because the per-slice fixed cost amortises better; largest fixture
wins 76 ms absolute on the radiologist-relevant 16M-voxel CT.
Sub-linear vs N=8 cores because:
- Z-delta probe is serialized
- Slices 0-1 are sequential
- Memory contention on the 16M-voxel CT writes 33 MB of output
Architectural change:
- Per-slice body extracted into encodeOneSlice(...) instance
method so sequential + parallel paths share the same logic.
- From slice 2 onward neither tile-mode flag mutates, so the
parallel closure captures the committed flags by value.
- Z-delta correctness preserved: residual depends on raw INPUT
bytes, not on the encoded codestream of the previous slice.
Combined with v10.11-v10.13 decode wins: round-trip on the
16M-voxel CT is ~3.5× faster vs v10.10.0.
Validation:
- swift test --filter JP3D regression 519/519 PASS (codestream
bytes-identical to v10.13.0; parallel encode = serial encode
under the same Z-delta gating)
- Mandatory commit gate (release mode) 7/7 PASS
Codestream bytes byte-identical to v10.13.0; decoder unchanged.
MINOR per RELEASING.md — internal refactor only, same encoder
API and output bytes.
Opt-out via J2K_JP3D_PARALLEL_ENCODE=0.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
JP3DSliceStackCodec.encodesplits the previously-sequential per-slice loop into sequential slices 0-1 (commits the M6/M7 Z-delta tile-mode decision) + parallel slices 2..N via TaskGroup.Correctness gate (release mode)
swift test --filter JP3DregressionJ2KMedicalCorpusEncodePerformanceTestsJ2KMedicalCorpusPerformanceTestsJ2KStrictCrossCodecValidationTestsTest plan
Companion documents
RELEASE_NOTES_v10.14.0.md— full release notesDocumentation/Benchmarks/data/jp3d-bench-arm64-v10_23-parallel-encode-20260524.json— A/B raw (parallel)Documentation/Benchmarks/data/jp3d-bench-arm64-v10_23-serial-encode-20260524.json— A/B raw (serial baseline)v10.23-researchbranch perfeedback_research_no_main_merge.md.🤖 Generated with Claude Code