It changes over time as the task sizes change.

Just take a look at the task page for a completed task. Look at the output at the bottom of the page. It lists the FFT size. Multiply that by 8, and that's the amount of cache you need for one task.

Or just ask for about a specific sub-project and somebody can look up what the current FFT sizes are. This is usually a good idea for conjecture projects and GCW, which have different FFT sizes depending on the K or B.

That being said, here's the current (maximum) FFT sizes for active LLR tasks. Multiply these numbers by 8:

So if I take MEG 262144 x 8 = 2,097,152

What does that number tell me? I need 2MB L3 per work unit? Those are bytes?

So if I take MEG 262144 x 8 = 2,097,152

What does that number tell me? I need 2MB L3 per work unit? Those are bytes?

That's fine, but you actually need more cache than minimum because the O/S, and even the BOINC client itself, has a habit of stealing some of your CPU cycles and cache lines.

Ideally, we would be running a BOINC-client based O/S that would function similar to DOS.

That's fine, but you actually need more cache than minimum because the O/S, and even the BOINC client itself, has a habit of stealing some of your CPU cycles and cache lines.

How does FFT change? I assume it doesn't increase by 1.

How does FFT change? I assume it doesn't increase by 1.

Does the FFT memory access pattern already maximize the cache hit ratio?

A project's memory access pattern is relevant when you have less than the optimal amount of cache.
For instance, if your cache size is a little bit less than what you need to fit the whole thing in cache, then
getting the next larger size of cache may not be worth the marginal increase in speed,
when the cache hit ratio is already over, say, 99%.

At the opposite extreme, a cache hit rate of 0% makes the cache useless.
This happens with an array larger than the cache size, and you repeatedly
cycle through the array from beginning to end. With a LRU replacement policy,
this access pattern replaces existing cache entries just before they are needed.
If allowed by the algorithm, an improved access pattern would be to reverse
the direction of stepping through the array each cycle, thus avoiding cache misses
except at both ends of the array.

The way I understand it is that FFT sizes need to get bigger when you do tests on bigger numbers. This is to keep the required accuracy so the result does not have errors. There are some sweet spot FFT sizes which is what gets used.

As for buying a CPU, generally I wouldn't worry about it unless you really intend to optimise PrimeGrid work over all else. Even then, you can consider which projects you're interested in. Running a task fast is not the same as getting the most tasks done in a given time.

That's exactly what I do hope to do.

Yes, FFT increases with bigger numbers being tested. I focus on SOB tasks. Based on the chart posted earlier I'm looking at 3932160*8 = 31,457,280. I'm going to round up and call it 32 MB per task.

Maybe I can find a processor with 32 MB and it will be adequate for todays tasks. But what happens when FFT increases? First question is how much does it increase at a time? Will the next increase bump it up to 33 MB? Or will the next increase bump it up to 36 MB? or double it to 64 MB? Or something else? I assume those "sweet spot FFT sizes" are known. What's the next one? What are the next 20?

If that information is known, the next question is how often does FFT increase? Does it increase with each individual task? Does it increase when tasks double in size? Will the next "sweet spot FFT size" come into play when tasks are just a bit bigger than they are now, or not until they are a lot bigger than now?

I understand that I'm concerned with future happenings. I also know that making predictions is difficult (especially about the future). Which is why I'm hoping there is a chart of FFT vs time, or a general rule that someone can look at and interpolate from. Can I say FFT doubles every month? Every year? Every 3 years? etc.

Then I can say I'll likely need XXX MB L3 cache to fit the tasks expected for the next Y years. Then I can look at cpu's and select one based on that info.

Does the FFT memory access pattern already maximize the cache hit ratio?

FFT sizes going up depends on the distribution of candidates to test and how many people are going through those tests. At best it is a moving target but I'd say it is relatively slow. It is not going to double in a month, and I wouldn't expect a doubling in the magnitude of a year unless it was a very new subproject and things are moving fast. SoB feels slow, in more ways than one. Actually, you could look up known SoB primes and run the test on them manually to see what FFT was used. Combined with discovery date you have some kind of history, and can attempt extrapolation at your own risk.

You can see the FFT steps if you run a Prime95 benchmark on your system. LLR uses the same FFT code so they can be carefully used to try and work out performance. Note you may see different FFT sizes used on different CPUs, e.g. Ryzen vs Intel.

Some testing I did in the past which tries to show the performance considerations graphically. Skimming through it again, I think that was before AVX-512 support.
https://linustechtips.com/topic/838473-cpu-performance-with-prime95-293/

Easy rule of thumb: buy the CPU with the biggest cache that fits in your budgets (initial outlay and power bill). In terms of currentishly available options, if you want it to last a long time, think AMD 5900X/5950X (64MB 12/16c) or take a chance on the supposed-to-be-released-already 5800X3D (96MB 8c). If you've got the money to burn, go high-core count Cascade Lake-X desktop or -SP Xeons, Ice Lake-SP Xeons, or Epyc 7xx3 (ordered by increasing cost). Honorable mention to Threadripper (up to 256MB cache), but it's stuck on last gen architecture.

Does the FFT algorithm use the whole memory allocation throughout the calculation,
or does it have a peaking usage pattern where releasing some of the memory part way
through the calculation would benefit other tasks requiring cache? If the latter, two tasks
can be synchronized without actually releasing the memory, with a shared mutex so that
one task is allowed to use more cache while the other needs less cache. In this situation
the mutex is acting like a traffic cop at an intersection. The cache's bandwidth usage would
be maximized rather than becoming congested by attempted simultaneous maximum demand.

Easy rule of thumb: buy the CPU with the biggest cache that fits in your budgets (initial outlay and power bill). In terms of currentishly available options, if you want it to last a long time, think AMD 5900X/5950X (64MB 12/16c) or take a chance on the supposed-to-be-released-already 5800X3D (96MB 8c). If you've got the money to burn, go high-core count Cascade Lake-X desktop or -SP Xeons, Ice Lake-SP Xeons, or Epyc 7xx3 (ordered by increasing cost). Honorable mention to Threadripper (up to 256MB cache), but it's stuck on last gen architecture.

Keep in mind that the desire for cache is to allow the CPU cores to run at their maximum potential without being held back by ram performance. If the cache requirement is met, performance can scale with cores. If work goes beyond the cache, then ram performance will become relevant.

A big caution with AMD CPUs: the L3 cache may not be unified. The 12/16 core Zen 3 models are two CCX, so are best seen as two lumps of 32MB, not one lump of 64MB. I'll have to say I've not done any testing on them since Zen 2, but to my understanding of the architecture there is no way to directly share data between each L3 cache segment (CCX) without going out to ram. Internal bandwidth of AMD CPUs is generally comparable to dual channel ram bandwidths, so it would get congested fast if multiple segments try to do so at the same time. It still shows some improvement but doesn't scale near where it could be had the cache been unified.

The upcoming 5800X3D does have 96MB of unified cache but only 8 cores. You have practically unlimited performance of those 8 cores. Note with such a large cache, you will probably get more throughput running two SoB tasks with 4 cores each than one task of 8, as it is more efficient the fewer threads you use on a single task. 3 tasks might even be higher throughput still but you'd have to find a way to manage 3+3+2 core split to try it, and it might not be great long term given how close it is to the limit already.

Can't remember where it popped up, but someone on here did do some tests with big tasks across CCX's and while it wasn't the best scaling, it was still noticeably faster (by throughput) than running 1 task per CCX and going to main memory.

I am very tempted by the 5800X3D, myself, but the sad reality is that I can pick up a used Skylake-X/Cascade Lake-X setup with more cores for less than it would probably cost, and having AVX-512+quad channel memory, would vastly outperform the AMD, even if the task is bigger than the cache.

https://www.ecmwf.int/sites/default/files/medialibrary/2022-01/NL-170-C3-DellAcqua-Figure-2.jpg

In modern meteorology, spherical harmonics direct and inverse transforms intensively use the FFTW library to solve Navier-Stokes equations in the spectral domain on multiple nodes multiple sockets multiple cores.
The "ECMWF HPC2020" european facilities are dedicated to weather prediction and climate change.
FFTW especially features an auto tuning functionality to adapt to all kind of topology and architecture ...
Keeping the hands on the software implementation details is most of the time a very valuable approach too!