CMake/ITKSetStandardCompilerFlags.cmake:163-172 advises users on AVX-512
hardware to add -mprefer-vector-width=256, but that advice is unquantified and
the two issues it cites (#2634, #1939) are both closed. Local benchmarks suggest
the advice is correct and should be promoted to documented, measured guidance.
Measured evidence — Sapphire Rapids Resample sweep
Host: Intel Xeon w7-3545 (Sapphire Rapids), GCC 13.3. Four-config Resample
benchmark sweep:
| Variant |
-march=x86-64-v4 vs baseline |
| Affine-only |
+17% to +20% |
| BSpline-dominated |
−12% to −17% |
The regression is not localized to one hot function. The v4 build emits
53,063 zmm instructions across 4,977 functions, versus 162 zmm instructions
at baseline. That breadth keeps the CPU in the AVX-512 license-throttled P-state
essentially all the time (throttle persistence measured at ~670 µs after the
last wide instruction). BSpline TransformPoint is memory-latency-bound, so
wider vectors buy it nothing while the lower clock costs it directly.
Proposed work
- Re-run the sweep with
-march=x86-64-v4 -mprefer-vector-width=256.
Hypothesis: recovers the Affine speedup without the BSpline regression.
- Repeat on at least one non-Intel AVX-512 part (Zen 4/5, which has no
license-based frequency throttle) to determine whether the guidance is
Intel-specific or universal.
- Survey whether any ITK kernel family measurably benefits from 512-bit
width. If none does, promote the CMake comment to explicit documentation
that -mprefer-vector-width=256 should always accompany -march=x86-64-v4,
and update CMake/ITKSetStandardCompilerFlags.cmake to say so with the
measurement attached.
Note that ITK sets no architecture flags by default; this is guidance for
downstream builders and packagers, not a default-behavior change.
Why the referenced issues are dead
So the CMake comment currently points readers at three dead references.
CMake/ITKSetStandardCompilerFlags.cmake:163-172advises users on AVX-512hardware to add
-mprefer-vector-width=256, but that advice is unquantified andthe two issues it cites (#2634, #1939) are both closed. Local benchmarks suggest
the advice is correct and should be promoted to documented, measured guidance.
Measured evidence — Sapphire Rapids Resample sweep
Host: Intel Xeon w7-3545 (Sapphire Rapids), GCC 13.3. Four-config Resample
benchmark sweep:
-march=x86-64-v4vs baselineThe regression is not localized to one hot function. The v4 build emits
53,063 zmm instructions across 4,977 functions, versus 162 zmm instructions
at baseline. That breadth keeps the CPU in the AVX-512 license-throttled P-state
essentially all the time (throttle persistence measured at ~670 µs after the
last wide instruction). BSpline
TransformPointis memory-latency-bound, sowider vectors buy it nothing while the lower clock costs it directly.
Proposed work
-march=x86-64-v4 -mprefer-vector-width=256.Hypothesis: recovers the Affine speedup without the BSpline regression.
license-based frequency throttle) to determine whether the guidance is
Intel-specific or universal.
width. If none does, promote the CMake comment to explicit documentation
that
-mprefer-vector-width=256should always accompany-march=x86-64-v4,and update
CMake/ITKSetStandardCompilerFlags.cmaketo say so with themeasurement attached.
Note that ITK sets no architecture flags by default; this is guidance for
downstream builders and packagers, not a default-behavior change.
Why the referenced issues are dead
-march=corei7,-mtune=generic, and dead code"). TheITK_X86_64_ISA_LEVELoption that PR proposed does not exist on
main.So the CMake comment currently points readers at three dead references.