AltaLux V2 introduced a substantially more ambitious image-processing pipeline: instead of the single-scale enhancement used by the original plugin, V2 processes every image through three CLAHE layers (fine, balanced, and smooth) and blends their results into the final image. That produces better control over local contrast and a more natural result, but it also means more computation, as every pixel participates in repeated luminance extraction, histogram processing, interpolation, layer accumulation, and color reconstruction.
Making that pipeline fast required more than extending the usage of SIMD intrinsics. It required a way to determine, kernel by kernel, when vectorization actually helped. The decisive step was therefore not SSE2 or AVX2 by itself, but adding a benchmark for every performance-critical kernel and giving Codex a measurable optimization target.
Establishing a scalar reference
The optimization work began by moving the important inner loops behind a common kernel interface. Each operation received a scalar implementation that served three purposes:
- It defined the expected behavior.
- It provided a correctness reference for SIMD implementations.
- It established the performance baseline against which every optimization could be measured.
The extracted kernels covered the complete processing path:
- RGB and BGR luminance extraction
- Multiplicative luminance re-injection
- Packed YUV luminance extraction and injection
- RGB24 and RGB32 2× box downscaling
- Multiscale layer accumulation
- Weighted image output
- CLAHE histogram construction
- Histogram clipping and mapping
- CLAHE interpolation
This separation was essential for benchmarking performance at the right level. When all of these operations were embedded in larger filter methods, an end-to-end timing could show that the filter was faster or slower, but it could not explain why. Once each loop became a named kernel, every optimization had its own observable result.
Kernel vectorization: SSE2 and AVX2
The initial vectorized implementation introduced SSE2 and AVX2 paths alongside the scalar baseline. Runtime dispatch selected the best implementation supported by the processor, as backward compatibility with older CPUs must be preserved. SSE2 provided a portable SIMD foundation for x86-64 systems. It was particularly useful for operations built around contiguous integer arithmetic:
- Expanding packed bytes into wider integer lanes
- Calculating weighted luminance values
- Scaling color channels
- Accumulating weighted image layers
- Rounding, packing, and writing results back to byte buffers
The scalar implementation continued to handle tails that did not fill an entire vector. This kept the SIMD loops straightforward while preserving support for arbitrary image sizes.
Correctness tests compared the SSE2 and AVX2 output directly with scalar output. Optimization then had two independent gates:
- a candidate had to match the pixels produced by the reference implementation
- it had to improve the benchmark results.
Why AVX2 was not automatically twice as fast
AVX2 doubled the integer vector width from 128 to 256 bits, but a wider register does not guarantee a proportional speedup. Image data, especially weird ones like RGB24, does not naturally align with SIMD lanes, as three-byte pixels cross vector boundaries, and extracting or reconstructing their channels can require expensive shuffle sequences. Some kernels are limited by memory bandwidth rather than arithmetic throughput. Others depend on indexed memory access or on the result of the previous iteration.
So the AVX2 work concentrated on kernels that could process useful blocks of contiguous data. Shuffle-based paths were developed for RGB24 luminance extraction and 2× box downscaling, while wider vector width accelerated layer accumulation and final writeback.
The benchmark suite made it possible to judge these implementations by elapsed time rather than by instruction count or theoretical lane width. If additional unpacking, shuffling, or temporary storage consumed the benefit of wider vectors, the result was immediately visible.
Benchmarks became the optimization loop
AltaLuxBench was expanded so that every critical kernel could be executed independently with scalar, SSE2, and AVX2 dispatch. The benchmark workload uses deterministic 3840×2160 image buffers, representing a realistic 4K processing load. Each implementation receives warm-up executions before measurement. The harness then automatically increases the batch size until a sample lasts approximately 100 milliseconds, up to a maximum of 512 operations. Fifteen samples are collected for every implementation. Scalar and SIMD measurements are rotated during sampling to reduce ordering and temperature bias, and the median time per operation is reported. SIMD results also include their speedup relative to scalar.
That design gave Codex a stable, machine-readable feedback loop:
- Identify a hot kernel.
- Implement or revise its SIMD path.
- Build and run the correctness tests.
- Benchmark scalar, SSE2, and AVX2 variants.
- Retain the candidate only when it improved the measured result.
- Move to the next kernel.
End-to-end filter benchmarks complemented the microbenchmarks. Serial and parallel filter paths were measured for packed YUV, BGR24, and BGR32 images, ensuring that a faster isolated kernel also benefited real processing.
Once the objective and validation criteria were in place, Codex could repeat this loop without asking the user to review intrinsics, select implementations, or interpret each intermediate result. The benchmarks supplied the decision signal; the unit tests supplied the safety boundary.
When the benchmark says “keep it scalar”
The most valuable result of benchmarking every kernel was discovering where SIMD instructions should not be used.
For example, the CLAHE histogram construction performs an indexed increment:
histogram[pixel]++
Several SIMD lanes can reference the same histogram bin, creating write conflicts. Neither SSE2 nor AVX2 can safely convert that operation into a simple packed loop. Histogram mapping contains a prefix sum, so each output depends on the preceding value. Histogram clipping ends with stateful redistribution. CLAHE interpolation performs grey-value-indexed map lookups; SSE2 has no integer gather instruction, and vectorizing only the construction of the row maps benchmarked slower than the scalar implementation.
Codex experimented where there was a plausible vectorization opportunity, measured the result, and retained scalar fallbacks when the complete SIMD path was not a clear win, so a AVX2 entry point may call the scalar kernel when scalar is faster for that operation.
SSE2 evolves into SSSE3
The benchmark-guided process also revealed that SSE2 was not the best instruction-set for the 128-bit tier. Several important image operations benefited from byte-shuffle instructions introduced with SSSE3. The SSE2 tier was consequently replaced with an SSSE3 implementation, allowing more efficient channel rearrangement for:
- RGB luminance extraction
- Multiscale accumulation
- Weighted writeback
- RGB24 and RGB32 2× box downscaling
The final V2 dispatch order is therefore AVX2, then SSSE3, then scalar..
Optimization beyond intrinsics
Kernel measurements also exposed costs that were not solved by parallel processing. AltaLux V2 now avoids parallel overhead on smaller images. It uses blocked parallel accumulation and output only from 200,000 pixels upward, and runs the three CLAHE layer passes concurrently only for images of at least one million pixels.
The color-reinjection path uses a 1 KiB reciprocal lookup table instead of performing division for every pixel and retaining the older 64 KiB two-dimensional scale table. This improves both arithmetic cost and cache behavior.
Autonomous, evidence-driven optimization
Codex was able to drive the optimization process without continuous user intervention because the specifications given to the tool encoded the definition of success:
- The scalar implementation defined correctness
- Unit tests enforced output equivalence
- Per-kernel benchmarks measured local performance
- Full-filter benchmarks checked the practical result
Together, those mechanisms turned optimization into a closed feedback loop rather than a sequence of subjective code reviews.
