If you're willing to put in the work finding the FFT jumps (fun detective work IMO) and per-iteration times (not as fun; you may not want to run full tests the whole way like I did up to 512K), you can plug them into LLRTools ([url]https://www.mersenneforum.org/showpost.php?p=62302&postcount=35[/url]) and let that spit out the average test time for any range.

Happy - you sure you can't do better with a stick in the sand than that?

I could write a script to automate finding those FFT jumps? (It would help me immensely too.) Pick a language. I'm good at most common ones. :)

To be honest, I'm not sure who I was supposed to be answering. I thought I was coming up with a solution for your removal rate dilemma, if that hasn't already even been solved. My posts-per-page count (19) is such that I don't have the post you replied to on this page anymore.

@diep
I've created the [url='https://www.rieselprime.de/ziki/Riesel_prime_32767']Riesel k=32767[/url] in the Wiki and reserved it for you (including tested to n=50k).
I've also updated the k=89 reservation. If you got any further results for k=32767 please fill them in.

Kar, c'est bon!

You can be sure i will report it if there is a new one above n=1569 :)

Please note for the few who might not know: testspeed of LLR with larger k's is a lot slower than small k's. k = 89 and k=69 here tests roughly factor 2 faster than k=32767, under the same conditions.

At the CPU's with many cores here what matters most is that LLR FFT-size stays within combined L3 cachesize : #cores * L3_cache_a_core

I do not know details yet the FFT-size seems dependant upon which k-factor you use.

(so if you know the FFT size for that specific k-factor and n-size in units multiply it with 16 bytes - because the size is in doubles and you need 1 double which has t he information and 1 to write new information to,
and a double is 64 bits so that's 8 bytes and you need 2 of that makes 16 bytes. The blabla from manufacturers that you can add up the L2 and L1 cachesize to it seems utter blabla from the manufacturers to me by the way yet that's not relevant here - just L3 cachesize matters there in that comparision - except if you do not have a L3 cache then L2 cache size matters. So to say it technical the algorithm doesn't seem to work in-situ regrettably)

[QUOTE=diep;564551]I do not know details yet the FFT-size seems dependant upon which k-factor you use.[/QUOTE]

According to that LLRTools tool I linked, to go from the max [I]n[/I] for [I]k[/I]=1 of a given FFT length (which I'll call [$]n_m[/$]) to the max [I]n[/I] for any [I]k[/I] for that same FFT length (which I'll call [$]n_k[/$]), the formula is [TEX]n_k = n_m - (\log_2 k + \frac{1}{2}(\log_2 k)(fftlen))[/TEX].

Here is the promised script. It's a little slow, and I haven't tested it on Windows (I don't currently have access to a Windows box), but it's completely automated once started. It uses a binary search (which it prints out) to find the minimum [I]n[/I] for every FFT length below a given limit (provided on the command line; you can give the exact number or a "K" or "M" suffixed one like LLR prints out; the actual length doesn't have to be present on that platform). It dynamically finds the relevant FFT lengths for that platform through the search. Create a "temp" subfolder as a working directory for it to dump all of the temp files (it creates a ton of them). It uses the CLI version of LLR (assuming its name is "llr" in the current directory). Let me know if anyone finds this useful.

[QUOTE=Happy5214;564652]Here is the promised script. It's a little slow, and I haven't tested it on Windows (I don't currently have access to a Windows box), but it's completely automated once started. It uses a binary search (which it prints out) to find the minimum [I]n[/I] for every FFT length below a given limit (provided on the command line; you can give the exact number or a "K" or "M" suffixed one like LLR prints out; the actual length doesn't have to be present on that platform). It dynamically finds the relevant FFT lengths for that platform through the search. Create a "temp" subfolder as a working directory for it to dump all of the temp files (it creates a ton of them). It uses the CLI version of LLR (assuming its name is "llr" in the current directory). Let me know if anyone finds this useful.[/QUOTE]

How to use the script?
What do i type on the command line?

something like this?

python happy.py 32767 5800000

k=2805
 

Releasing k=8847 and reserving k=2805.

[QUOTE=diep;564875]How to use the script?
What do i type on the command line?

something like this?

python happy.py 32767 5800000[/QUOTE]
To be honest, I use Linux, so I'd just set the executable flag and the shebang (the first comment line with the Unix-style interpreter path) would do the rest. You appear to be using Windows, though, given that invocation. It uses Python 3, so I think you'd call "python3" instead of "python" (which calls Python 2). At least that's how it works on Ubuntu.

You have the arguments flipped. The [I]max FFT length[/I] ([I]not[/I] the max [I]n[/I]) is the first one, since it's the only required one. The [I]k[/I] you choose for the optional second argument shouldn't change the result significantly unless it starts zero-padding the FFTs (high 6-digits), and I chose [I]k[/I]=100005 to avoid zero-padding while still shortening the timing tests (since the [I]n[/I]'s will be lower). [I]n[/I]=5.8M is at the 480k FFT length for your [I]k[/I] on my Core 2 Quad, and the Xeon won't be too much different, if at all, so run it to that or 512k. Something like "python3 happy.py 480K".

I've attached another script that reads in the generated maxlen.txt and converts the max [I]n[/I]'s (which are adjusted in the file to match Mersenne values) for any chosen [I]k[/I]. They should closely match the test results from the verbose printouts of the first script. It's called using "python3 fftlen.py [I]k[/I]".

I posted those two scripts (renamed to generate_maxlen.py and adjusted_fftlen.py) and a few others to a new GitHub repo: [url]https://github.com/happy5214/rps-scripts[/url]. I'll post updates there. You'll need the fftlen.py library module for both scripts. I plan on adding a new argument interface to generate_maxlen.py to allow you to specify a max [I]n[/I] instead of a max FFT length, and also to specify verbosity via a flag instead of by editing the code.