`cppauto` and AVX/AVX2 support + question

[Qubitol]

Currently, cppauto resolves the backend within this block in cudacpp.mk:

ifeq ($(BACKEND),cppauto)
  ifeq ($(UNAME_P),ppc64le)
    override BACKEND = cppsse4
  else ifeq ($(UNAME_P),arm)
    override BACKEND = cppsse4
  else ifeq ($(wildcard /proc/cpuinfo),)
    override BACKEND = cppnone
    ###$(warning Using BACKEND='$(BACKEND)' because host SIMD features cannot be read from /proc/cpuinfo)
  else ifeq ($(shell grep -m1 -c avx512vl /proc/cpuinfo)$(shell $(CXX) --version | grep ^clang),1)
    override BACKEND = cpp512y
  else
    override BACKEND = cppavx2
  # ...
  endif
endif

So it means it will look for AVX512 and if not available, it will fall back to AVX2.
I think this may not be the right behaviour in some particular cases:

The CPU supports only SSE and not AVX/AVX2

I must say I'm don't know if this is possible, or if hardware of this kind exist
In this case, it will fall back to AVX2, and crashing during execution.

The CPU supports only AVX and not AVX2

This is the case of Intel(R) Xeon(R) CPU E5-2695 v2.
In this case it will still fall back to AVX2, so it will be compiled with -march=haswell.
Is this ok in this scenario?

Additionally, at runtime, we check explicitly (MatrixElementKernelHost::hostSupportsSIMD using __builtin_cpu_supports("avx2"), and I'm quite sure that would fail in this particular scenario.

What do you think? Should we add multiple checks for both SSE and AVX?

[valassi]

Hi @Qubitol just a quick comment. I discussed a few related points in https://arxiv.org/abs/2510.05392v3 that will appear tomorrow.

The main point is, there are zillions of combinations possible, but with the none/sse4/avx2/512y/512z I tried to cover only a few specific cases (also avoiding native as we discussed).

Specifically:

• 512z is best on CPUs with two AVX512 FMA units (eg Intel Xeon Gold 6326)
• 512y is best on CPUs with one AVX512 FMA unit (eg Intel Xeon Silver 4216)
• avx2 is best on all AVX2 CPUs with no AVX512 (many on the grid) and also covers non-Intel with 256 bit registers
• sse4: interesting that you mention E5-2695 with AVX but no AVX2, in this case I guess that it is best to use sse4 (unless someone wants to introduce a specific flag for that)
• none: be aware as discussed in Tests and minor performance improvements for FPTYPE=m color sums on CPU #1073 (and in the paper) that "-march=x86-64" disables SSE4.2 but does not disable SSE and SSE2; the interest of none was actually only as reference point for no-SIMD, but if at some point you want to make this a real no-SIMD, you'd better disable autovectorization too (my mistake at the beginning)

Otherwise, check what the experiments do. At some point I will interface madgraph4gpu to LHCb, and there we use x86 feature levels like v1, v2, v3. If you ever think of changing 'none, sse4" etc for something else, I would strongly suggest that. (The 512y/512z is a tricky business, it is not even available in the O/S, maybe one day this will be published as an OS feature, maybe not: I think a CUDACPP-specific hack is needed there).

Hope this helps, cheers
Andrea

[Qubitol]

Hi @valassi, thank you for your comment.
Indeed, the combinations are a lot. The idea is not to support all of them, but to have sane defaults, I think.

• 512z is best on CPUs with two AVX512 FMA units (eg Intel Xeon Gold 6326)
• 512y is best on CPUs with one AVX512 FMA unit (eg Intel Xeon Silver 4216)

These indeed should not change.

• avx2 is best on all AVX2 CPUs with no AVX512 (many on the grid) and also covers non-Intel with 256 bit registers
• sse4: interesting that you mention E5-2695 with AVX but no AVX2, in this case I guess that it is best to use sse4 (unless someone wants to introduce a specific flag for that)

In the way it is coded in case of cppauto, we just do a fallback to AVX2, and this may fail on some hardware.
Maybe we can do a check starting from the most vectorised (check for AVX512-related flags) to the least vectorised (SSE4), falling back to none and picking up the first match that we get.
This would ensure that it always works, with the worst case scenario being that we pick SSE over AVX when, example for Ivy Bridge microarchitecture (which is old!), there is AVX, no AVX2, but there is SSE4. I'd say this may be a reasonable compromise, given, as you said, AVX2 is supported by many CPUs on the grid.

[valassi]

In the way it is coded in case of cppauto, we just do a fallback to AVX2, and this may fail on some hardware. Maybe we can do a check starting from the most vectorised (check for AVX512-related flags) to the least vectorised (SSE4), falling back to none and picking up the first match that we get. This would ensure that it always works, with the worst case scenario being that we pick SSE over AVX when, example for Ivy Bridge microarchitecture (which is old!), there is AVX, no AVX2, but there is SSE4. I'd say this may be a reasonable compromise, given, as you said, AVX2 is supported by many CPUs on the grid.

Ah sure you are right I had not thought of that. I think that this really only applies to few old nodes, but it is a valid bug fix. Anyway, do what you think is best, I am planning to move to other things so I would not touch this (unless you want me to).

Cheers
Andrea

[Qubitol]

I'm planning to fix this, it's not a difficult fix.