I think there was a post in the past that had FFT sizes for each project, but I can't find it again. Anyone know where it was? It is possible it would be out of date also, so is there some way I can find current values short of looking at random units?

Why? Ryzen 3000 (Zen 2) was launched yesterday, and comes with at least 32MB of L3 cache. I expect to get my sample on Tuesday and bench it. Based on what I currently understand of it, it has potential to be the best choice for LLR use in terms of a balance of power consumption, compute performance, and pricing. FFT size will allow a more educated guess into the optimal running configuration, which I can then test with benchmarks.

I think there was a post in the past that had FFT sizes for each project, but I can't find it again. Anyone know where it was? It is possible it would be out of date also, so is there some way I can find current values short of looking at random units?

Why? Ryzen 3000 (Zen 2) was launched yesterday, and comes with at least 32MB of L3 cache. I expect to get my sample on Tuesday and bench it. Based on what I currently understand of it, it has potential to be the best choice for LLR use in terms of a balance of power consumption, compute performance, and pricing. FFT size will allow a more educated guess into the optimal running configuration, which I can then test with benchmarks.

Thanks Michael, looks like they will comfortably fit in the L3 cache so it could give some interesting performance numbers, all going well. Will write more once I've tested, hopefully tomorrow.

Thanks Michael, looks like they will comfortably fit in the L3 cache so it could give some interesting performance numbers, all going well. Will write more once I've tested, hopefully tomorrow.

What immediately catches the eye when switching between the two results is the new 16MB L3 cache capacity which doubles upon the 8MB of Matisse. We have to remind ourselves that even though the whole chip contains 64MB of L3 cache, this is not a unified cache and a single CPU core will only see its own CCX’s L3 cache before going into main memory, which is in contrast to Intel’s L3 cache where all the cores have access to the full amount.

I'm very interested in AVX-512 performance on these. I've been waiting for a couple years to upgrade to something with good AVX-512 and a good amount of cache.

The more I learn, the less great this CPU series seems.

The bandwidth between the cores and IO is asymmetric, with only half speed writes.
All data leaving a CCX goes through IO die, even if the destination is another CCX on the same die.
That the L3 cache is not unified means running 8 cores on one task might not be so great. Treating it as 2x4 cores is probably better.

Still, my CPU has been dispatched so I hope to bench tomorrow evening.

Ok, I wont start a new thread for now. Too much data and not enough conclusion. I don't have an image host to put the chart here, but it is at the following link along with a description of the testing.
https://linustechtips.com/main/topic/1080453-ryzen-3600-vs-8086k-for-prime-number-finding/

The question here is probably how fast is Zen 2? Well, the provisional result is they have matched Intel in FPU performance, and with optimisations to how you run tasks, the bigger cache means it can maintain higher performance at bigger FFT sizes.

Note the following is a prediction of throughput based on the Prime95 benchmark data. Do not complain to me if you see differently in reality, as I have also seen discrepancies between theory and reality. That will be for later testing to confirm or otherwise.

I'm comparing my 8086k and the 3600 with a better cooler than it comes with. Clocks did seem to fluctuate with temperature on the 3600.

For small tasks (SGS, PPSE, PPS) running one per core the 8086k takes a small lead, presumably from its higher clock, but the 3600 is close behind.

Mega is in an awkward spot for the 8086k, as it isn't fully efficient one per core, nor running -t3. Maybe -t2 would be better but that was not a tested condition. This size is no problem for the 3600 and it should be faster.

Into the mid sizes (TRP, SR5, 321, ESP) it is better to run the 8086k with 1 task of 6 threads as all the cache is needed to feed it. The 3600 differs here, and two tasks of 3 cores each was more optimal. This is probably due to the 32MB cache actually being split into two separate 16MB regions, so one task per region gives best performance. Running a single task with 6 cores was significantly below that.

The bigger tasks are where the differences really show. GCW, Woo, Cul, PSP, SoB are beyond the 8086k cache and performance drops down towards that afforded by the ram speed. I was only using 3000 which is wholly inadequate to feed it, and it would take about double that. The 3600 still at two tasks of 3 cores each could still do these excluding SoB with high performance, up to 50% faster than the 8086k. For leading edge SoB work the relative performance of the 3600 drops, presumably as it has now exceeded the 16MB chunk size of L3 cache and it is partially hitting ram again. Still, running a single task on 6 threads here gives significantly greater performance than the 8086k.

To recap:
Small units: run 1 task per core on either CPU
Medium units: run 1 task 6 cores on Intel, 2 tasks 3 cores on 3600.
Large units: 1 task 6 cores on both systems, but 3600 will be much faster.

I didn't run 3 tasks of 2 cores each on either system. It should be viable on 8086k and may fill the small performance hole observed at Mega size units. It probably isn't a good idea on the 3600 as you can't divide two cache chunks into 3 equal units, but the bigger cache allows you to jump from 1 to 3 cores per task anyway.

Similar principles could be applied to 8, 12, 16 core models.

I would add the CPU ran hotter than I'd expect, given it wasn't taking that much power in the greater scheme of things, and I had an upgraded over stock cooler. It was running ball park 80C. There is speculation that although the power might not be high, the die is relatively small so power density is the problem. I'm not sure there is a good solution for that. Maybe the 8 core per die models will have more of a cooling problem.

Note I'm running PPSE on the 3600, 1 per core, and will leave it going overnight. If you look up the system, ignore the 1st 12 units done as I mistakenly left in -t2 from previous usage and was also doing things with affinity. It is looking slightly faster than a 6700k I'm using as reference, even though the 6700k is at 4 GHz and 3600 averaged around 50MHz under.

Would it be fair to say...

1) It looks like AMD finally built a CPU with full AVX performance.

2) The huge cache is a big advantage for those FFTs where the FFT fits in the Ryzen cache but not in the Intel cache.

3) Ryzen is now competitive with Intel unless you go with a (dual unit) AVX-512 CPU.

Is that correct?
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

Wow mackerel, thank you so much for that.

To Michael's questions:
1, the AVX performance is now comparable to Intel consumer CPUs. I still need further testing to get a more precise figure on that.
2, yes, the cache helps it work faster in more situations. I've seen similar with the desktop Broadwell CPUs, which had 128 MB L4 cache. Basically it didn't matter what ram you had attached to it. I was running it single channel for a time when I had a shortage and performance remained high.
3, same as #1, but a two unit AVX-512 CPU has more potential, as well as more heat resulting from that. Even at stock I don't consider my 7800X to be safe as it hits 100C with high end air cooler.

A later test will be performance per watt, and I suspect the 3600 will be ahead in that too.

What are the units of the FFT sizes in the table?
Do those sizes represent all the data needed for the FFT plus the additional software prefetched data?

the gwnum library that LLR uses will modify in place where necessary.
so it's a relatively static and localised data structure (i think).
especially if it lives fully in your cache!
____________

Each element is a complex (i.e., real + imaginary) number consisting of 2 64-bit double precision floating point numbers. That's 8 bytes for each number. I believe you need space to store 3 copies of that so you can do a multiply operation such as C = A * B, so the total memory usage should be 24 times the FFT size.

I've only ever seen and used 8x up to this thread and I don't see any evidence to use otherwise.

The basic operating state for gwnum is for a single core on a single task. Running multiple tasks, and/or multi-threaded tasks takes a little more consideration.

I think George had said in the past the multi-thread code isn't the best, and breaks up the work into smaller bits before re-assembling them. So the practical result of that is, smaller tasks don't scale well running multiple threads.

With normalised data from Prime95 benchmark it is possible to see how different scenarios behave. In general, if the total footprint of all running tasks is less than the L3 size, you generally get good performance. This could be simplified as FFT size * 8 * number of tasks running < L3 cache size. If you exceed L3 cache size, then ram bandwidth enters into the equation. Ram bandwidth shortage is the biggest limitation for bigger tasks. Dual channel is wholly inadequate for >4 core fast cores (most Intel Core CPUs, Zen 2 Ryzen). Running a single task multi-thread helps in this scenario.

HT is a complicated matter. I've only occasionally seen hints that, in some limited scenarios, it can give an uplift in performance compared to not having/using it. In general it doesn't seem to give any significant boost but still increases power consumption. There are also scenarios where it can be used to lessen losses e.g. Windows scheduler has sucked in past, don't know if it changed since then. Running multiple single thread tasks one per core without affinity could lower throughput by ~10%. Affinity resolves that, turning off HT resolves that, or running more threads than cores resolves that (at higher power usage).

Been thinking about it a bit. If you can't test with llr, is it possible to try with prime95? Might be worth a post on mersenneforum.

To refresh this with new data. I buy 3900X and comparing it with I5-9500K ( six core without HT)

Ryzen
Prime95 64-bit version 29.8, RdtscTiming=1
Timings for 480K all-complex FFT length (12 cores, 4 workers): 0.57, 0.58, 0.58, 0.58 ms. Throughput: 6926.95 iter/sec.
Timings for 480K all-complex FFT length (12 cores, 6 workers): 1.62, 0.85, 1.62, 0.85, 0.57, 0.57 ms. Throughput: 7067.52 iter/sec.
Timings for 480K all-complex FFT length (12 cores, 12 workers): 1.64, 1.63, 1.62, 1.62, 1.62, 1.62, 1.63, 1.64, 1.62, 1.62, 1.62, 1.63 ms. Throughput: 7375.00 iter/sec.
Timings for 480K all-complex FFT length (12 cores hyperthreaded, 4 workers): 0.53, 0.53, 0.53, 0.53 ms. Throughput: 7544.68 iter/sec.
Timings for 480K all-complex FFT length (12 cores hyperthreaded, 6 workers): 1.52, 0.78, 1.52, 0.78, 0.53, 0.53 ms. Throughput: 7651.88 iter/sec.
Timings for 480K all-complex FFT length (12 cores hyperthreaded, 12 workers): 1.52, 1.52, 1.52, 1.53, 1.52, 1.53, 1.52, 1.52, 1.53, 1.53, 1.53, 1.53 ms. Throughput: 7869.45 iter/sec.


Intel
Prime95 64-bit version 29.8, RdtscTiming=1
Timings for 480K FFT length (6 cores, 1 worker): 0.36 ms. Throughput: 2785.83 iter/sec.
Timings for 480K FFT length (6 cores, 2 workers): 0.67, 0.66 ms. Throughput: 3002.62 iter/sec.
Timings for 480K FFT length (6 cores, 3 workers): 1.48, 1.47, 1.43 ms. Throughput: 2055.82 iter/sec.
Timings for 480K FFT length (6 cores, 6 workers): 4.13, 3.84, 3.88, 3.95, 3.91, 3.79 ms. Throughput: 1532.76 iter/sec.

Test case 480K
You first look where you got most of output: Ryzen - 12 workers Intel 2 workers

Ryzen average is 1.53 ms ,average Intela 0.67 ms

Lets say 480 K has 5000000 itterations

Ryzen 5000000*1.53=7650000/1000 ( milisecond to second)=7650 sec per results and /12 it has 12 workers = 637,5 second per result

Day have 86400 seconds so Ryzen will make 135 results per day

Intela 5000000*0.67=3350000/1000=51 results per day

Intel 768K 0.55 ms 1 worker 6 cores
Ryzen 768K all-complex FFT, 12 cores 4 workers. Average times: 0.84, 0.84, 0.84, 0.84 ms. Total throughput: 4745.09 iter/sec.

7500000 *0.55=4125 sec 86400/4125 = 20,94 per day 2.7M digits
7500000 *0.84=6300 sec / 4= 1575 86400/1575 54,98per day 2.7M digits

Both CPU ran at same speed and RAM is at same speed. Since Intel has only 6 cores you must have 2 CPU , 2 MB to power supply, and you still will have 1/3 lower output.

All that cover AVX-512 that add additional boost , but those Intel CPU cost more then AMD

So for this money I think AMD Ryzen 3900 is very nice CPU.



____________
92*10^^1585996-1 NEAR-REPDIGIT PRIME :) :) :)
4 * 650^⁴⁹⁸¹⁰¹-1 CRUS PRIME
2022202116^¹³¹⁰⁷²+1 GENERALIZED FERMAT
Proud member of team Aggie The Pew. Go Aggie!

Prime95 64-bit version 29.8, RdtscTiming=1
Timings for 480K all-complex FFT length (12 cores, 4 workers): 0.57, 0.58, 0.58, 0.58 ms. Throughput: 6926.95 iter/sec.

Timings for 480K all-complex FFT length (12 cores hyperthreaded, 12 workers): 1.52, 1.52, 1.52, 1.53, 1.52, 1.53, 1.52, 1.52, 1.53, 1.53, 1.53, 1.53 ms. Throughput: 7869.45 iter/sec.

Prime95 64-bit version 29.8, RdtscTiming=1
Timings for 480K all-complex FFT length (12 cores, 4 workers): 0.57, 0.58, 0.58, 0.58 ms. Throughput: 6926.95 iter/sec.

Timings for 480K all-complex FFT length (12 cores hyperthreaded, 12 workers): 1.52, 1.52, 1.52, 1.53, 1.52, 1.53, 1.52, 1.52, 1.53, 1.53, 1.53, 1.53 ms. Throughput: 7869.45 iter/sec.

for the 4 thread test were you running 3x4threads? For smaller tasks (ie not SoB) I find 1x8 is significantly slower than 2x4 on my 3700x. Your results show the same if you were only running 1x4.

Interesting results Crun-chi. At 480k, the sensible combinations of cores/workers fit in the L3 cache, so as you see higher throughput efficiency is seen when using fewer cores per worker. I find it particularly interesting the with-SMT results are a good % higher still. I don't think I ever tested it on Zen 2 systems. Will have to see if I can repeat it on my single CCD models.

I do have a 7920X (12 cores, with AVX-512) so could try to run a set on that for comparison. The system is currently set up for gaming and is behaving a bit oddly under P95, so I'll need to check the settings on it. As fixed clock was mentioned, what was that clock for test?

I think reason is :480k is too small result for such big cache, so 12 x 1 is still better option
____________
92*10^^1585996-1 NEAR-REPDIGIT PRIME :) :) :)
4 * 650^⁴⁹⁸¹⁰¹-1 CRUS PRIME
2022202116^¹³¹⁰⁷²+1 GENERALIZED FERMAT
Proud member of team Aggie The Pew. Go Aggie!

Prime95 64-bit version 29.8, RdtscTiming=1
Timings for 480K all-complex FFT length (12 cores, 4 workers): 0.57, 0.58, 0.58, 0.58 ms. Throughput: 6926.95 iter/sec.

Timings for 480K all-complex FFT length (12 cores hyperthreaded, 12 workers): 1.52, 1.52, 1.52, 1.53, 1.52, 1.53, 1.52, 1.52, 1.53, 1.53, 1.53, 1.53 ms. Throughput: 7869.45 iter/sec.

for the 4 thread test were you running 3x4threads? For smaller tasks (ie not SoB) I find 1x8 is significantly slower than 2x4 on my 3700x. Your results show the same if you were only running 1x4.

I dont understund what you ask?
3 cores per worker , 4 worker =12 cores
So every worker has 3 cores, and 4 worker works in parallel in same time.
So for 480K on 12 workers with 2 cores ( 1 core real+1 cores SMP) give me the fastest output

It's interesting as I've found for any of the "multithreading recommended" tasks that 4 cores each is fastest for the smaller ones and using all 8 cores for SoB is best.

It's interesting as I've found for any of the "multithreading recommended" tasks that 4 cores each is fastest for the smaller ones and using all 8 cores for SoB is best.

It's complicated, and it also depends on what your optimisation is towards.

right, that answers my question.
so you're saying multhreading was a waste of time for you and 12 workers/cores had the highest throughput?

It's interesting as I've found for any of the "multithreading recommended" tasks that 4 cores each is fastest for the smaller ones and using all 8 cores for SoB is best.

This is benchmark from Prime95 up to 960K.
I will never go such high, but I select it so boundary when Ryzen is better to 4*3 cores worker become visible.

https://www.dropbox.com/s/l1jdjjmpx3q6rch/results.bench.txt?dl=0

Notice configuration on every FFT with 6*2 cores: aspect ratio between workers is nearly same in whole range

3.15, 1.59, 3.15, 1.60, 1.07, 1.07 ms

1 and 3 has same value
2 and 4 has same value
5 and 6 has same value.

Maybe it is bug in hwloc maybe it is how Ryzen is designed: I dont know
____________
92*10^^1585996-1 NEAR-REPDIGIT PRIME :) :) :)
4 * 650^⁴⁹⁸¹⁰¹-1 CRUS PRIME
2022202116^¹³¹⁰⁷²+1 GENERALIZED FERMAT
Proud member of team Aggie The Pew. Go Aggie!

Having just acquired a 3950x I'm a little puzzled by the performance.
If I've understood everything above then an ESP task @ 1440k will fit into the cache so on my 3700x I've been running 2 of these with 4 threads and they take about 24K seconds to complete.
On the 3950x they're taking 39K seconds each when running 4 even though the 3950x is running at 4.2GHz vs 4GHz of the 3700x.
Are the tasks actually hitting main RAM and running into bandwidth limitations?

Run Prime95 benchmark, set 1440K and see what will produce best output ( fastest)
That is best answer you can get because then you will see what is best on your computer
____________
92*10^^1585996-1 NEAR-REPDIGIT PRIME :) :) :)
4 * 650^⁴⁹⁸¹⁰¹-1 CRUS PRIME
2022202116^¹³¹⁰⁷²+1 GENERALIZED FERMAT
Proud member of team Aggie The Pew. Go Aggie!

Run Prime95 benchmark, set 1440K and see what will produce best output ( fastest)
That is best answer you can get because then you will see what is best on your computer

Run Prime95 benchmark, set 1440K and see what will produce best output ( fastest)
That is best answer you can get because then you will see what is best on your computer

I did that. It suggests to run 4 tasks with 4 threads as expected.
My question is why those tasks are taking 39000seconds on the 3950x vs 24000 seconds running 2 tasks on the 3700x which in theory is just half a 3950x.

Run Prime95 benchmark, set 1440K and see what will produce best output ( fastest)
That is best answer you can get because then you will see what is best on your computer

I did that. It suggests to run 4 tasks with 4 threads as expected.
My question is why those tasks are taking 39000seconds on the 3950x vs 24000 seconds running 2 tasks on the 3700x which in theory is just half a 3950x.

Could it be that 4 tasks of 1440k FFT will overload the cache?

Having just acquired a 3950x I'm a little puzzled by the performance.
If I've understood everything above then an ESP task @ 1440k will fit into the cache so on my 3700x I've been running 2 of these with 4 threads and they take about 24K seconds to complete.
On the 3950x they're taking 39K seconds each when running 4 even though the 3950x is running at 4.2GHz vs 4GHz of the 3700x.
Are the tasks actually hitting main RAM and running into bandwidth limitations?

Having just acquired a 3950x I'm a little puzzled by the performance.
If I've understood everything above then an ESP task @ 1440k will fit into the cache so on my 3700x I've been running 2 of these with 4 threads and they take about 24K seconds to complete.
On the 3950x they're taking 39K seconds each when running 4 even though the 3950x is running at 4.2GHz vs 4GHz of the 3700x.
Are the tasks actually hitting main RAM and running into bandwidth limitations?

Your problem is likely windows. Tasks run fastest when they stay on within a chiplet on Zen2. That way they don't have to transfer data over the bus within the CPU. For some reason, Windows is horrible at keeping a multithreaded task on a single chiplet with Zen2. Linux is much better, with results being much quicker.

See the thread here:

http://www.primegrid.com/forum_thread.php?id=9063&nowrap=true#139003
http://www.primegrid.com/forum_thread.php?id=9063&nowrap=true#139603

Having just acquired a 3950x I'm a little puzzled by the performance.
If I've understood everything above then an ESP task @ 1440k will fit into the cache so on my 3700x I've been running 2 of these with 4 threads and they take about 24K seconds to complete.
On the 3950x they're taking 39K seconds each when running 4 even though the 3950x is running at 4.2GHz vs 4GHz of the 3700x.
Are the tasks actually hitting main RAM and running into bandwidth limitations?

Your problem is likely windows. Tasks run fastest when they stay on within a chiplet on Zen2. That way they don't have to transfer data over the bus within the CPU. For some reason, Windows is horrible at keeping a multithreaded task on a single chiplet with Zen2. Linux is much better, with results being much quicker.

See the thread here:

http://www.primegrid.com/forum_thread.php?id=9063&nowrap=true#139003
http://www.primegrid.com/forum_thread.php?id=9063&nowrap=true#139603

I just created a mint usb and ran some 4xESP and 4xSR5 tasks.

After 5 minutes running for each batch the ETCs were:
ESP: 27000 (windows 39000)
SR5: 7500 (windows 9500)

That's a massive improvement so thanks Zombie + Crun-chi.

I just created a mint usb and ran some 4xESP and 4xSR5 tasks.

After 5 minutes running for each batch the ETCs were:
ESP: 27000 (windows 39000)
SR5: 7500 (windows 9500)

That's a massive improvement so thanks Zombie + Crun-chi.

3700x 5800 seconds windows managed.
3950x 8400 seconds windows managed.
3950x 6000 seconds after I discovered process lasso and told it to give each llr an equal cpu share which confines each task to a single ccx.

An update for anyone following this with a Ryzen. For the moment I'm still using windows as I haven't had time to get linux up and running for a proper test.
With Process Lasso confining tasks to a ccx I'm now seeing runtimes 10% faster than on the 3700x.
eg: 3700x: ESP 1440k ~24000 seconds
3950x: ESP 1440k ~ 22000 seconds

This means the problem was also present on the 3700x but there's clearly far less of a performance hit crossing CCXs within a ccd vs crossing CCDs.

If you want to try out process lasso you can find it here: link.

What you need to do is go into options, cpu, configure instance balancer.
Add "primegrid_cllr.exe" as the process and select "equal cpus per instance". Note that this is only going to work if you're using all your real cores.

Thanks for the follow-up remarks Sheridan. A lot of people have noticed indeed the rather disappointing but still impressive results from Ryzen 3-gen when not setting affinity and not checking the exact CCX/CCD architecture per CPU. I know that some who have Ryzen are using a program written by ATN, which in essence assigns/or sets affinity for some general PG or PGS programs. It refreshes every x seconds and checks whether it needs to bind more processes to certain artificial nodes. Btw: I have not dived into Lasso yet, but will do!

Thanks for the follow-up remarks Sheridan. A lot of people have noticed indeed the rather disappointing but still impressive results from Ryzen 3-gen when not setting affinity and not checking the exact CCX/CCD architecture per CPU. I know that some who have Ryzen are using a program written by ATN, which in essence assigns/or sets affinity for some general PG or PGS programs. It refreshes every x seconds and checks whether it needs to bind more processes to certain artificial nodes. Btw: I have not dived into Lasso yet, but will do!

Or just install linux :)

Mint is here.
In my experience they're all much the same - fine once they're up and running the way you want but a pain to get to that point unless terminals and arcane commands are your thing (I use ubuntu for development work).

I use debian net install: since I have written my own scripts for mprime, for setup linux box I need 30 minutes: everything I do , I do remote on linux shell: do in under Windows.
Setup, run and forget :)
____________
92*10^^1585996-1 NEAR-REPDIGIT PRIME :) :) :)
4 * 650^⁴⁹⁸¹⁰¹-1 CRUS PRIME
2022202116^¹³¹⁰⁷²+1 GENERALIZED FERMAT
Proud member of team Aggie The Pew. Go Aggie!

Re FFT sizes, the GCW project spans a wide range of FFTs, most of which run will run fastest with 4 threads but 1920K would be faster with 8.
Is there any way we could get an FFT range selection alongside the number of threads option?

Re FFT sizes, the GCW project spans a wide range of FFTs, most of which run will run fastest with 4 threads but 1920K would be faster with 8.
Is there any way we could get an FFT range selection alongside the number of threads option?

you mean just wanting an extra 20% throughput isn't a good enough reason? ;-)

As it's a single subproject affected at this time then if it's a lot of work I agree it doesn't make sense to do it.

Or just install linux :)

After over month of experimenting new data is here.
This is real data (under mprime Linux)

[Worker #1 Jul 5 22:36:45] Starting PRP test of 4*53^1608950+1 using all-complex FMA3 FFT length 640K, Pass1=512, Pass2=1280, clm=2, 6 threads
[Worker #1 Jul 6 01:51:01] 4*53^1608950+1 is not prime. RES64: 985B646C621A8710. Wh8: A6218917,00000000

24+60+60+51 195 min

[Worker #2 Jul 20 05:50:36] Starting PRP test of 4*53^1613198+1 using all-complex FMA3 FFT length 640K, Pass1=512, Pass2=1280, clm=2, 6 threads
[Worker #2 Jul 20 09:51:40] 4*53^1613198+1 is not prime. RES64: 6F5E857A6F1844E4. Wh8: C751AA47,00000000

10+60+60+60+51 241 min

-------------------------------------------------------------------------------------------------------------
AFTER FLASHING NEW AGESA BIOS and disable HT

[Worker #4 Jul 25 17:32:05] Starting PRP test of 4*53^1618262+1 using all-complex FMA3 FFT length 640K, Pass1=512, Pass2=1280, clm=2, 3 threads
[Worker #4 Jul 25 19:32:30] 4*53^1618262+1 is not prime. RES64: B08543B377E72BF8. Wh8: A496D1D7,00000000

120 min (and few seconds more)

Conclusion
1. If your board maker release new AGESA flash it. In my case reduce nearly 10 A of cpu power consumption.
2. Dont lower voltage too much: CPU will work, CPU will be stable but as you can see performance is terrible.
3. Turn HT of , that gives me more then 6 A smaller CPU power consumption: so before this I have in average 80 °C , now I cannot pass 66 °C
Times are way better then before.

This month was good spent time on tuning CPU ... now just to find some primes :)

____________
92*10^^1585996-1 NEAR-REPDIGIT PRIME :) :) :)
4 * 650^⁴⁹⁸¹⁰¹-1 CRUS PRIME
2022202116^¹³¹⁰⁷²+1 GENERALIZED FERMAT
Proud member of team Aggie The Pew. Go Aggie!

The data is a bit confusing, what was the running configuration of the earlier two states? In particular, were you using 50% of threads or all of them? I have seen using the extra SMT threads for LLR work increases power consumption somewhat, and in most cases doesn't result in more throughput.

Also it is unclear what was done when, is the improvement due to the new AGESA, the removal of SMT, or perhaps a combination of both? Do you know the AGESA version (not bios version, as that will vary on motherboard) as it will give an indication of what changes happened at what time.

The data is a bit confusing, what was the running configuration of the earlier two states? In particular, were you using 50% of threads or all of them? I have seen using the extra SMT threads for LLR work increases power consumption somewhat, and in most cases doesn't result in more throughput.

Also it is unclear what was done when, is the improvement due to the new AGESA, the removal of SMT, or perhaps a combination of both? Do you know the AGESA version (not bios version, as that will vary on motherboard) as it will give an indication of what changes happened at what time.

I've just discovered something important for Ryzen users who want to run projects with FFT size that goes to ram (ie anything >= 1920K).
If you have 16GB ram you'll probably want to throw it away and get yourself 32GB.

Why? As 8GB ram sticks are currently single rank whereas 16GB sticks are dual rank.

Running prime95 with 16GB ram, single rank sticks, for fft size 3200 on a 3950x returns best performance of 626iter/sec for running 2 tasks with 8 threads each.

Running prime95 with 32GB ram, dual rank sticks, for fft size 3200 on a 3950x returns best performance of 1015iter/sec for running 2 tasks with 8 threads each.

To put that in primegrid terms, a 3200K SoB task would take 28 hours with single rank ram.
With dual rank it will take around 20 hours.

With dual rank it will take around 20 hours.

That is exactly the same throughput as a 9960X running 1 task of 12 threads.
Or a 9980XE running 1 task of 14 threads.
Time of 10 hours.

I've just discovered something important for Ryzen users who want to run projects with FFT size that goes to ram (ie anything >= 1920K).
If you have 16GB ram you'll probably want to throw it away and get yourself 32GB.

Why? As 8GB ram sticks are currently single rank whereas 16GB sticks are dual rank.

You're right about ram speed, possibly because of the timings - 3200 cl16 and 3600cl18 are about the same performance-wise.

You're right about ram speed, possibly because of the timings - 3200 cl16 and 3600cl18 are about the same performance-wise.

You're right about ram speed, possibly because of the timings - 3200 cl16 and 3600cl18 are about the same performance-wise.

Or a 9980XE running 1 task of 14 threads.
Time of 10 hours....

lol if amd make this for 20+ hours,,, some "hypotheticall" 4950X amd will not help much .. there is more than 50% difference!! even "amd 8950" willl not help ))))
Amd must make radicall changes on architecture and forget "cinebench marketing" and i say it like owner of 1950/2990wx-trash cpu and death platform x399, trx40 is already death platform and amd is too noise about amd pro cpus and wr80 chipset and mobos..

The soon to be released 4950X could be fast?

On the Intel front, it is a strange world that the 9960X is so much better than the 9980XE at PG and yet it probably isn't known because I suspect I have the only 2 9960Xs at PG.

Latest stats on SOB (not a lot of data I know):
I've run 4 x 16 thread tasks on 2 x 9960X - average time 26,674 sec - 3.24 SOB tasks / day
I've run 2 x 16 thread tasks on a 9980XE - average time 31,403 sec - 2.75 SOB tasks / day
The 9960Xs are consistently faster and have more throughput than the 9980XE for all tasks at PG.
If the 10980XE is faster than the 9960X, it wouldn't be by much. And it is 50% more expensive.

Stats on SGS (I didn't write down how many tasks / day - just the difference between computers - I think it was around 3500 tasks / day for the 9960Xs)
The new 9960X was doing 16 single thread tasks of SGS as was the 9980XE. 18.8% faster / task than the 9980XE.
The old 9960X was doing 16 single thread tasks of SGS. 17.3% faster / task than the 9980XE.

There is one thing that needs to be said about Woo (and probably Cul too) re: FFT size:
On the 9960X, 2 tasks each of 8 threads runs times of about 19,500 sec.
If you allocate 2 threads for the GPU and run 2 tasks of 7 threads the times are around 27,000 - 28,000 sec. If you run 1 task of 14 threads (with 2 threads for GPU) you get times of about 11,900 sec.
The times on the 9980XE with 2 x 8 thread tasks and 2 threads for GPU are around 23,500 sec.

The 9980XE has 2 Mb more L2 cache (which won't make any difference if you are running 16 threads for LLR / sieve on any of these computers) but has 2.75 Mb more L3 cache.

I think the 9960X is a much better CPU because that was the intended design? Intel added 2 more cores in response to AMD and created the xx80XE CPUs.

Apologies if I've gone really off topic.

Or a 9980XE running 1 task of 14 threads.
Time of 10 hours....

lol if amd make this for 20+ hours,,, some "hypotheticall" 4950X amd will not help much .. there is more than 50% difference!! even "amd 8950" willl not help ))))
Amd must make radicall changes on architecture and forget "cinebench marketing" and i say it like owner of 1950/2990wx-trash cpu and death platform x399, trx40 is already death platform and amd is too noise about amd pro cpus and wr80 chipset and mobos..

Or a 9980XE running 1 task of 14 threads.
Time of 10 hours....

Hi,

There seems to be a bit of disagreement in regards to calculating the approximate L3 footprint of the various PG WUs. The difference between multiplying by 8 or 24 is pretty large! Is there a reason why 8x seems to work in practical terms when 24x appears to be the theoretical answer?

I think there was a post in the past that had FFT sizes for each project, but I can't find it again. Anyone know where it was? It is possible it would be out of date also, so is there some way I can find current values short of looking at random units?

Why? Ryzen 3000 (Zen 2) was launched yesterday, and comes with at least 32MB of L3 cache. I expect to get my sample on Tuesday and bench it. Based on what I currently understand of it, it has potential to be the best choice for LLR use in terms of a balance of power consumption, compute performance, and pricing. FFT size will allow a more educated guess into the optimal running configuration, which I can then test with benchmarks.

Current values:

+-------+----------------------------------------+------+------+ | appid | user_friendly_name | min | max | +-------+----------------------------------------+------+------+ | 2 | Sophie Germain (LLR) | 128 | 128 | | 3 | Woodall (LLR) | 1440 | 1920 | | 4 | Cullen (LLR) | 1536 | 1920 | | 7 | 321 (LLR) | 800 | 800 | | 8 | Prime Sierpinski Problem (LLR) | 1920 | 2048 | | 10 | PPS (LLR) | 192 | 192 | | 13 | Seventeen or Bust | 2560 | 2880 | | 15 | The Riesel Problem (LLR) | 720 | 1008 | | 18 | PPSE (LLR) | 120 | 120 | | 19 | Sierpinski/Riesel Base 5 Problem (LLR) | 560 | 720 | | 20 | Extended Sierpinski Problem | 1280 | 1280 | | 21 | PPS-Mega (LLR) | 200 | 256 | | 30 | Generalized Cullen/Woodall (LLR) | 1440 | 1792 | +-------+----------------------------------------+------+------+

The SoB line includes post-DC n=31M candidates.

Is there a current version of this table?

Looking forward to the 4950x next month which is supposed to be 20% faster. ;-)

That sounds like some really good performance. I'll race you for throughput in SOB on a 9960X with 16 thread tasks?

On Zen 2, each CCD houses two core complexes (CCXs), whereby each complex is comprised of four cores that share 16MB of L3 cache. According to the AMD document, Zen 3's composition is completely different - there's only one CCX inside each CCD. The CCX possesses eight cores that can either run in single-thread (1T) or two-thread SMT (simultaneous multithreading) mode (2T), amounting up to 16 threads per complex. Since there's only one CCX now, all eight CPU cores can now directly access the 32MB of shared L3 cache.