This is ok, you are missed fact that you using 4 cores on candidate that have only 240/256K
So your resources are better exploited on 256K candidate and hence has lower computing time
But that is my version :)
____________
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!

Guess: FFT sizes that are a power of two are faster than those that aren't.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

Guess: FFT sizes that are a power of two are faster than those that aren't.

Guess: FFT sizes that are a power of two are faster than those that aren't.

This sounds like a potential optimization - step up FFT to the next power of two. Care to run some experiments?

Hi
llr3.8.23 mostly using FFT length 240K
llr3.8.21 mostly using FFT length 256K

Test on host
http://www.primegrid.com/results.php?hostid=946202

aww, I think 256k is faster
host 946571
____________
My lucky number is 6219*2^3374198+1

I just noticed this too, on 2 machines, using BOINC tasks over a span of 7 to 9 hours.

i5-4590T (4 cores, BOINC 100% CPU)
1 task @ 4 threads
240K FFT (average of 11 tasks) 1370 sec run time, 5099 CPU time
256K FFT (average of 7 tasks) 1802 sec run time, 6733 sec CPU time
240K FFT takes 32% more run time and 32% more CPU time than 256K FFT

i7-5820K (6 cores, HT on and BOINC 50% CPU)
3 tasks @ 2 threads each + AP27 on GPU
240K FFT (average of 11 tasks) 2645 sec run time, 4343 sec CPU time
256K FFT (average of 9 tasks) 3647 sec run time, 5535 sec CPU time
240K FFT takes 38% more run time and 27% more CPU time than 256K FFT

To prove or refute Crun-chi's conjecture that the larger FFT is better at exploiting multi-core hardware,
we would need to run PPS-MEGA tasks on a single-core system (no HT).
Does anyone have the CPU and the patience to try this?
FMA3 almost certainly isn't available on single-core hardware.

Without saying that it proves anything, we can test 1 task 1 thread on multicore systems,
thanks to the recently introduced PrimeGrid preferences for cores and tasks.
I will report my results in a subsequent post.

It seems counterintuitive that a shorter FFT would be slower.
Is this effect similar to using a shorter word size for large number computations?
The appropriate test of this would be to try a FFT size of 280K vs 256K.

In the end, if we can't undestand why 256K FFT is faster than 240K FFT,
we should just use what we know works better.
"Shut up and calculate", as N. David Mermin said (often misattributed to Richard Feynman).

I had previously made observations in a more generalised sense. In short, multi-thread scaling does seem to "work better" with larger FFT sizes up to the point you run out of cache and become ram bandwidth limited. Looking the other way, as FFTs get smaller, efficiency continues to fall. As a result of these factors, the sweet spot seems to be balancing threads/tasks to fit in your CPU cache without exceeding it.

These particular tasks have somewhat smaller FFTs. 256k FFT is kinda borderline for 2MB/core L3 cache CPUs, so on those 1 or two threads per task is probably optimal for throughput. For an i5 with only 1.5MB/core, 2 threads per task is probably better than 1. In either case, 4 is right out (unless you only care about run time and not throughput).

https://linustechtips.com/main/topic/1080453-ryzen-3600-vs-8086k-for-prime-number-finding/
Look at the 8086k 1w and 2w (workers=tasks) lines.

I'm now wondering if there is a way to force a (bigger) FFT size in LLR. If so, it would be interesting to manually run a 240k FFT test at 256k and compare.

I ran a bunch of single-thread tasks one at a time on my 6-core system.
The effect is still there, but much less pronounced than with multiple threads.
Averaging over 11 tasks for 240K FFT and 8 tasks for 256K FFT:
240K FFT used 6% more run time and 11% more CPU time for than 256K FFT.
The run time is skewed on a couple of tasks. Probably the internet was unavailable for a time.

Yes my tests were with live tasks, PPS-MEGA.
The k is only available to us if we peek in BOINC's slot directories, and that has to be done while the task is running. Technically feasible, but I'm not interested in doing this at the moment.

...those x parts does not complete their sin/cos calculations the same time and hence leaving one or more cores idle for a small time before doing next cos/sin calculation.

I also observed this behavior, apparently it was never really solved why it happened?

I also noticed this difference: Pass1=128 is small and Pass2=2K is large for the fast 256K tasks, while the slower 240K tasks have larger Pass1=1280 and smaller Pass2=192.

Also a = 3 for faster task and a = 5 for slower task.

What is the meaning of these parameters? Maybe they are the reason for the difference in CPU times?
____________
1281979 * 2^485014 + 1 is prime ... no further hits up to: n = 5,700,000