current llrSR5 workunits have 10.0 MBytes CPU cache footprint,
Correction:
up to 10.0 MBytes.
Currently running workunits on my Zen 2 computers show this assortment of transforms:
FMA3 FFT length 1M
FMA3 FFT length 1120K
FMA3 FFT length 1280K
negacyclic FMA3 FFT length 1M
negacyclic FMA3 FFT length 1152K
negacyclic FMA3 FFT length 1280K
zero-padded FMA3 FFT length 1280K
And currently running on Zen 4:
AVX-512 FFT length 1280K
negacyclic AVX-512 FFT length 1M
negacyclic AVX-512 FFT length 1152K
negacyclic AVX-512 FFT length 1200K
negacyclic AVX-512 FFT length 1280K
zero-padded AVX-512 FFT length 1280K
1M/1120K/1200K/1280K FFT lengths mean 8.0/8.75/9.375/10.0 MBytes size of FFT coefficients, each one having 64 bits.
I haven't seen "negacyclic" FFTs with LLR and LLR2, so this one seems to be new with PRST. Or LLR/LLR2 merely didn't report in the same way when they perfomed a negacyclic instead of a cyclic FFT (if they did). From a quick glance at a few workunits, FFT or zero-padded FFT is used to test candidates of the
k*5^
n−1 form, and negacyclic FFT to test the
k*5^
n+1 form.
I believe to remember that LLR and LLR2 already had special handling of projects which have both
n−1 and
n+1 exponents in candidates, and that implementation of this special handling caused a bit of delay of the transition of these projects from LLR to LLR2.
Unlike in the llrGGCW challenge in September with the very same PRST binary, I have not seen it crashing on Zen 2 with segmentation violation yet, nor failing in any other way.