[FeatureRequest] Vectorization ratio should be computed differently

[rrzeschorscherl]

Is your feature request related to a problem? Please describe.
I think that the formula likwid-perfctr currently (5.5.1) uses to calculate the vectorization ratio on Intel x86 CPUs does not reflect what this metric is supposed to convey. Currently, the ratio tells what fraction of the floating-point instructions are of the vectorized type. IMO it should tell how much of the work is executed using vectorized instructions.

Describe the solution you'd like
Current formula for FP64 (for Intel CPUs):
100*(FP_ARITH_INST_RETIRED_128B_PACKED_DOUBLE+FP_ARITH_INST_RETIRED_256B_PACKED_DOUBLE+FP_ARITH_INST_RETIRED_512B_PACKED_DOUBLE)/(FP_ARITH_INST_RETIRED_SCALAR_DOUBLE+FP_ARITH_INST_RETIRED_128B_PACKED_DOUBLE+FP_ARITH_INST_RETIRED_256B_PACKED_DOUBLE+FP_ARITH_INST_RETIRED_512B_PACKED_DOUBLE)

Suggested formula:
100*(2*FP_ARITH_INST_RETIRED_128B_PACKED_DOUBLE+4*FP_ARITH_INST_RETIRED_256B_PACKED_DOUBLE+8*FP_ARITH_INST_RETIRED_512B_PACKED_DOUBLE)/(FP_ARITH_INST_RETIRED_SCALAR_DOUBLE+2*FP_ARITH_INST_RETIRED_128B_PACKED_DOUBLE+4*FP_ARITH_INST_RETIRED_256B_PACKED_DOUBLE+8*FP_ARITH_INST_RETIRED_512B_PACKED_DOUBLE)

[TomTheBear]

Thanks for your request.

Vectorization ratio as is was added quite some time ago without much discussion. I have no strong opinion on the naming but when I looked around what others defined, LIKWID's vectorization ratio is only fullfilling parts of it. Condensed from the sources, the vectorization ratio is defined as the ratio of scalar vs vector instructions.

The LIKWID metric uses instructions on Intel but limits the instructions to floating-point instructions, so a better name would be DP FP vectorization ratio (and SP ...) since it leaves out all the other vector instructions. This metric would only be available like that for Intel.

AMD systems (Zen1-4) do not provide events for FP instructions but FP operations. There are no events to differentiate between FP operations being executed due to vectorized or scalar instructions. With AMD Zen5, you get events that count by register widths but then you cannot differentiate between SP/DP. There are individual events but I have not checked whether there are enough registers to measure them all in one go. It is unlikely as they always count operations thus the MERGE event is required in every odd-numbered counter.

The situation on ARM is almost like on AMD. For Nvidia Grace and Fujitsu A64FX, you measure FP operations but you can differentiate between operations done by scalar or vector instructions. But you do not get the actual width of the executed instruction (NEON, SVE128, SVE256 or SVE512), so you cannot derive the amount of instructions from the operation counts.

Are you ok with changing the metric names of the original metric to DP FP vectorization ratio and SP ... repectively on Intel? For your proposed metric, I would name it DP FP vec. ops ratio and SP ... respecively. For AMD and ARM systems, we can introduce the FP vec. ops ratio without the separation in single- and double-precision.

[rrzeschorscherl]

I suggest to name "my" metric "vectorization ops ratio." If a differentiation between SP and DP is not possible then I suggest to stick with the instruction-based metric because SP and DP would give different values (a scalar loop in SP has twice the instruction weight than in DP because the SIMD width is doubled for all SIMD variants). Better to use a well-defined metric than one which may be off by 2x.
It's unfortunate that this cannot be made consistent across CPUs. Another option would be to drop the vectorization ratio for all CPUs where it cannot be calculated unambiguously.