|
DWT
I found this:
[url]http://groups.yahoo.com/group/primenumbers/message/7510[/url] How long before an implementation :question: |
Any day now:)
A quote from my forums at [url]www.rieselsieve.com[/url] First...a run with the new program and Using the standard Proth mode LLR (and SSE2 features) : [Sun Mar 14 22:56:22 2004] 3*2^414840-1 is prime! Time : 950.222 sec. [Sun Mar 14 23:43:53 2004] 3*2^584995-1 is prime! Time : 2851.126 sec. [Mon Mar 15 01:06:26 2004] 3*2^702038-1 is prime! Time : 4953.934 sec. [Mon Mar 15 02:31:05 2004] 3*2^727699-1 is prime! Time : 5076.015 sec. Now...notice with Using IBWT, but not SSE2 features : fftlmers = 28672, fftlen = 30790, fftlenmax = 57344, FFTLEN = 32768 [Sun Mar 14 20:40:52 2004] 3*2^584995-1 is prime! Time : 1528.484 sec. fftlmers = 40960, fftlen = 43878, fftlenmax = 81920, FFTLEN = 49152 [Sun Mar 14 21:28:25 2004] 3*2^702038-1 is prime! Time : 2853.473 sec. fftlmers = 40960, fftlen = 45482, fftlenmax = 81920, FFTLEN = 49152 [Sun Mar 14 22:17:31 2004] 3*2^727699-1 is prime! Time : 2945.688 sec. WHOA!!!!! Did you see that?...but wait.... Now look at Using IBWT and SSE2 :....O...the P4's and the AMD64's should kick some major ass. fftlmers = 28672, fftlen = 30790, fftlenmax = 65536, FFTLEN = 32768 [Sat Mar 20 17:03:07 2004] 3*2^584995-1 is prime! Time : 524.397 sec. fftlmers = 40960, fftlen = 43878, fftlenmax = 81920, FFTLEN = 49152 [Sat Mar 20 17:21:15 2004] 3*2^702038-1 is prime! Time : 1087.812 sec. fftlmers = 40960, fftlen = 45482, fftlenmax = 81920, FFTLEN = 49152 [Sat Mar 20 17:40:08 2004] 3*2^727699-1 is prime! Time : 1129.478 sec. As long as the k is under 9 bits in size....you get one hell of a bump in LLR speed. May this gift to you bring you many primes...FAST:) Lee Stephens B2 [url]www.rieselsieve.com[/url] O...it will be out soon...I'm sure Jean Penne will email you soon with details. |
[QUOTE=b2lee]
O...it will be out soon...I'm sure Jean Penne will email you soon with details.[/QUOTE] :w00t: :w00t: :w00t: I just can't WAIT!!! :bounce: :banana: :bounce: Luigi |
[QUOTE]I just can't WAIT!!![/QUOTE]
Me too :smile: :smile: :smile: To JP: :bow: |
New LLR ready!!!
Title says it all.
[url]http://groups.yahoo.com/group/primenumbers/[/url] Nice job Jean!!! regards, william |
[QUOTE=wfgarnett3]Title says it all.
[url]http://groups.yahoo.com/group/primenumbers/[/url] Nice job Jean!!! regards, william[/QUOTE] :bow: :bow: :bow: Where can I download the versions? I have no accesso to yahoogroups... :-( Luigi |
I have asked xyzzy to host it at primerib -- this will happen soon!
The gimps directory should also contain it soon! |
another problem of the new LLR
There seems to be another problem of the new version of LLR.
For some of the tests the initial guess of the FFT length is found to be too small, so it switches to the next higher one and restarts that test. This may happen after 5% of the test, but in most of my cases it happened when a test is almost done. And I cannot see any pattern or rule, if it happens for a given n or not. I should note that I'm using the Linux version, but I expect the same problem for the windows version too. So it seems that Jean needs to adjust the criterion for the initial guess a bit. Or is there a command line switch (as in PFGW) to use a larger FFT length for all the tests by default? I guess, not ... :sad: Another (minor) bug of the Linux version is, that you cannot stop the program by pressing <Ctrl><C> or any other key(s). You need to use the kill command with the "-KILL" (-9) switch, a normal "-STOP" (-15) doesn't work. May be this is somewhat related to the "save-file problem". Nevertheless, the speed of the new version of LLR is very exciting :w00t: Almost 4 times the speed of the older version, if the inital guess of the FFT length was right, and about 3 times as fast, if the next higher FFT length is used (not counting the "wasted" time of the aborted test by using the wrong FFT length). -- Thomas. |
[QUOTE]There seems to be another problem of the new version of LLR. For some of the tests the initial guess of the FFT length is found to be too small, so it switches to the next higher one and restarts that test.This may happen after 5% of the test, but in most of my cases it happened when a test is almost done. And I cannot see any pattern or rule, if it happens for a given n or not.
[/QUOTE] I was testing some numbers at n=860k and there seemed to be no problem but with the n=792k batch I am now testing there is the problem you mentioned. Perhaps we should test numbers that are larger until Jean fixes the problem -- they will have to be tested anyway and they might contain a prime :grin: |
[QUOTE=paulunderwood]I was testing some numbers at n=860k and there seemed to be no problem but with the n=792k batch I am now testing there is the problem you mentioned. Perhaps we should test numbers that are larger until Jean fixes the problem -- they will have to be tested anyway and they might contain a prime :grin:[/QUOTE]
This reminds me of a problem George had on the "crossover FFTs". I had my computer (with Windows 98) hung when I tried starting new LLR without deleting zxxxxx files. After that, no problems at all till now :banana: As I have a Mandrake 9.2 Linux 500 MHz 512 MB Xeon at office, I may try some tests starting from next Monday. Just let me know. :flex: Luigi |
[Wed Mar 24 12:40:59 2004]
3*2^831014-1 is not prime. Res64: F656B6EA1704FE45 Time : 1263.057 sec. Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 49152 [Wed Mar 24 13:02:22 2004] 3*2^831019-1 is not prime. Res64: C764647254B2531C Time : 1282.912 sec. Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 49152 fftlen seems to be too small, using next fftlen... Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 57344 [Wed Mar 24 13:30:12 2004] 3*2^831026-1 is not prime. Res64: 75BBADFFE526CAE9 Time : 1424.567 sec. Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 49152 [Wed Mar 24 13:49:58 2004] 3*2^831027-1 is not prime. Res64: EFDE6A7E009CDAEE Time : 1185.698 sec. Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 49152 [Wed Mar 24 13:56:40 2004] fftlen seems to be too small, using next fftlen... Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 57344 [Wed Mar 24 14:20:34 2004] 3*2^831038-1 is not prime. Res64: 75735AFF4F8FD78B Time : 1432.974 sec. Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 49152 [Wed Mar 24 14:36:05 2004] fftlen seems to be too small, using next fftlen... Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 57344 [Wed Mar 24 15:02:23 2004] 3*2^831051-1 is not prime. Res64: 4C5F0F6AC16A0464 Time : 1578.141 sec. Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 49152 [Wed Mar 24 15:24:25 2004] 3*2^831060-1 is not prime. Res64: D6C83EA9DFE74C81 Time : 1322.205 sec. Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 49152 [Wed Mar 24 15:41:29 2004] fftlen seems to be too small, using next fftlen... Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 57344 [Wed Mar 24 16:07:00 2004] 3*2^831074-1 is not prime. Res64: 5EC50BE51949C7EA Time : 1531.116 sec. Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 49152 [Wed Mar 24 16:29:00 2004] 3*2^831103-1 is not prime. Res64: B014FD8F483169FD Time : 1319.467 sec. Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 49152 fftlen seems to be too small, using next fftlen... Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 57344 [Wed Mar 24 16:55:33 2004] 3*2^831118-1 is not prime. Res64: 1BB9750BEF94F8D4 Time : 1477.510 sec. Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 49152 fftlen seems to be too small, using next fftlen... Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 57344 [Wed Mar 24 17:25:14 2004] 3*2^831124-1 is not prime. Res64: F797AA6B3852E936 Time : 1524.810 sec. Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 49152 fftlen seems to be too small, using next fftlen... Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 57344 [Wed Mar 24 17:52:15 2004] 3*2^831158-1 is not prime. Res64: 7D56EE98B64B97C4 Time : 1421.423 sec. Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 49152 [Wed Mar 24 18:11:51 2004] 3*2^831186-1 is not prime. Res64: 328C9687549BD027 Time : 1175.175 sec. Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 49152 [Wed Mar 24 18:31:27 2004] 3*2^831187-1 is not prime. Res64: 6C16ACDA88F4B57C Time : 1176.482 sec. Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 49152 [Wed Mar 24 18:51:04 2004] 3*2^831190-1 is not prime. Res64: AA0280681D0B510D Time : 1176.729 sec. Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 49152 fftlen seems to be too small, using next fftlen... Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 57344 [Wed Mar 24 19:18:32 2004] +016 is not prime. Res64: BE7E4DA9FFCAA01D Time : 1423.866 sec. Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 49152 [Wed Mar 24 19:37:45 2004] fftlen seems to be too small, using next fftlen... Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 57344 [Wed Mar 24 20:01:27 2004] 3*2^831211-1 is not prime. Res64: EE45C374064FD495 Time : 1422.365 sec. Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 49152 [Wed Mar 24 20:14:06 2004] fftlen seems to be too small, using next fftlen... Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 57344 [Wed Mar 24 20:37:50 2004] 3*2^831254-1 is not prime. Res64: 1E47B4482DD4EC3E Time : 1423.686 sec. Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 49152 [Wed Mar 24 20:57:35 2004] 3*2^831274-1 is not prime. Res64: BF97B1BE1CB62EF9 Time : 1185.339 sec. Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 49152 [Wed Mar 24 21:17:14 2004] 3*2^831275-1 is not prime. Res64: 18800BC1F26E2FE6 Time : 1178.563 sec. Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 49152 fftlen seems to be too small, using next fftlen... Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 57344 [Wed Mar 24 21:42:06 2004] 3*2^831279-1 is not prime. Res64: 2B4312540A805F89 Time : 1424.366 sec. Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 49152 [Wed Mar 24 21:51:42 2004] fftlen seems to be too small, using next fftlen... Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 57344 [Wed Mar 24 22:15:26 2004] 3*2^831298-1 is not prime. Res64: 598DD4B21FC8A73A Time : 1424.591 sec. Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 49152 [Wed Mar 24 22:32:53 2004] fftlen seems to be too small, using next fftlen... Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 57344 [Wed Mar 24 22:56:38 2004] +016 is not prime. Res64: A77EF71A9379D92E Time : 1424.921 sec. Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 49152 [Wed Mar 24 23:16:25 2004] 3*2^831324-1 is not prime. Res64: 45AEA527DB84926E Time : 1187.707 sec. Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 49152 [Wed Mar 24 23:24:42 2004] fftlen seems to be too small, using next fftlen... Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 57344 [Wed Mar 24 23:48:49 2004] 3*2^831340-1 is not prime. Res64: 19CCD089D7152082 Time : 1446.593 sec. Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 49152 [Thu Mar 25 00:08:35 2004] 3*2^831348-1 is not prime. Res64: 422D4C2F9B8D90D2 Time : 1185.654 sec. Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 49152 [Thu Mar 25 00:25:08 2004] fftlen seems to be too small, using next fftlen... Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 57344 [Thu Mar 25 00:48:49 2004] 3*2^831367-1 is not prime. Res64: D8C0EABE8CF51F6A Time : 1420.842 sec. Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 49152 [Thu Mar 25 01:08:31 2004] 3*2^831370-1 is not prime. Res64: 7B27736EACA472DD Time : 1181.452 sec. Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 49152 [Thu Mar 25 01:28:12 2004] 3*2^831391-1 is not prime. Res64: 0410FDF036C85053 Time : 1180.997 sec. Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 49152 [Thu Mar 25 01:47:52 2004] 3*2^831395-1 is not prime. Res64: 499AF886F63F9BD0 Time : 1180.241 sec. Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 49152 fftlen seems to be too small, using next fftlen... Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 57344 [Thu Mar 25 02:15:52 2004] 3*2^831400-1 is not prime. Res64: 68684FEB3240E311 Time : 1441.954 sec. Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 49152 [Thu Mar 25 02:28:33 2004] fftlen seems to be too small, using next fftlen... Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 57344 [Thu Mar 25 02:52:19 2004] 3*2^831415-1 is not prime. Res64: 8B3353D9E483DF63 Time : 1425.955 sec. Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 49152 fftlen seems to be too small, using next fftlen... Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 57344 [Thu Mar 25 03:20:43 2004] 016 is not prime. Res64: 2F58F7D5E67D75F1 Time : 1440.083 sec. Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 49152 [Thu Mar 25 03:30:02 2004] fftlen seems to be too small, using next fftlen... Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 57344 Im getting these +016 residues... anyone know what is going wrong here? Citrix :cool: :cool: :cool: |
[QUOTE][Wed Mar 24 18:51:04 2004]3*2^831190-1 is not prime. Res64: AA0280681D0B510D Time : 1176.729 sec.
Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 49152 fftlen seems to be too small, using next fftlen... Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 57344 [Wed Mar 24 19:18:32 2004] +016 is not prime. Res64: BE7E4DA9FFCAA01D Time : 1423.866 sec. Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 98304, Used fftlen = 49152] [/QUOTE] The "+016" should be 3*2^831198-1 -- another problem for Jean to resolve :surprised I will see if it happens here... |
Paul,
I know that! but do you know why it occurs every few residues. Is the source of the new LLR available, we can then fix it ourselves. Citrix :cool: :cool: :cool: |
The source is not available as far as I know. We will have to wait for Jean to return from his hols to fix the problems we have found. I suggest you test numbers at n=860k+ -- I did not have any problems there.
The good news is that I replicated your "016". I ran the number on both the new LLR and the old LLR. The residues were identicle. So look out for "016 is prime!" :wink: |
The source is now at [url]ftp://mersenne.org/llrsrc23.tgz[/url]
|
[QUOTE=Prime95]The source is now at [url]ftp://mersenne.org/llrsrc23.tgz[/url][/QUOTE]
[url]ftp://mersenne.org/gimps/llrsrc23.tgz[/url]... :wink: |
Here is what I got...
[code] [Wed Mar 24 20:05:19 2004] Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 81920, Used fftlen = 49152 [Wed Mar 24 20:14:50 2004] Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 81920, Used fftlen = 49152 [Wed Mar 24 22:00:36 2004] 3*2^779578-1 is not prime. Res64: 6B8852F173B8F57E Time : 6345.571 sec. Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 81920, Used fftlen = 49152 [Wed Mar 24 23:59:29 2004] 3*2^779594-1 is not prime. Res64: FFD7414ABBC5C86F Time : 7133.221 sec. Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 81920, Used fftlen = 49152 [Thu Mar 25 01:58:28 2004] 3*2^779630-1 is not prime. Res64: 99264EFB6BDE0675 Time : 7139.078 sec. Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 81920, Used fftlen = 49152 [Thu Mar 25 03:55:06 2004] 3*2^779686-1 is not prime. Res64: 3194D1B697E14E8D Time : 6997.449 sec. Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 81920, Used fftlen = 49152 [Thu Mar 25 05:52:37 2004] 3*2^779688-1 is not prime. Res64: 20E18317E49A9C85 Time : 7051.667 sec. Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 81920, Used fftlen = 49152 [Thu Mar 25 07:58:21 2004] 3*2^779715-1 is not prime. Res64: CE6C5B9C7EA29C5F Time : 7543.690 sec. Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 81920, Used fftlen = 49152 [Thu Mar 25 09:56:41 2004] 3*2^779736-1 is not prime. Res64: 106452A4D63BF408 Time : 7099.548 sec. Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 81920, Used fftlen = 49152 [Thu Mar 25 11:48:41 2004] 3*2^779740-1 is not prime. Res64: 463BEE4969C62DCE Time : 6719.686 sec. Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 81920, Used fftlen = 49152 [Thu Mar 25 13:39:57 2004] 3*2^779755-1 is not prime. Res64: CFEA72CAFB87170B Time : 6676.477 sec. Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 81920, Used fftlen = 49152 [Thu Mar 25 14:53:03 2004] fftlen seems to be too small, using next fftlen... Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 81920, Used fftlen = 57344 [Thu Mar 25 17:11:51 2004] 3*2^779778-1 is not prime. Res64: 22F30418629A811A Time : 8327.819 sec. Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 81920, Used fftlen = 49152 [Thu Mar 25 19:12:52 2004] 3*2^779786-1 is not prime. Res64: EE5CFA97CE7587C7 Time : 7261.165 sec. Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 81920, Used fftlen = 49152 [Thu Mar 25 21:03:46 2004] 3*2^779800-1 is not prime. Res64: 569E3E2B9E28F01E Time : 6653.489 sec. Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 81920, Used fftlen = 49152 [/code] Is range 998000-999000 :: 57 still available? :rolleyes: Luigi |
Book it and grab it [URL=http://www.mersenneforum.org/showthread.php?t=1545]here[/URL]
|
[QUOTE=Thomas11]
Another (minor) bug of the Linux version is, that you cannot stop the program by pressing <Ctrl><C> or any other key(s). You need to use the kill command with the "-KILL" (-9) switch, a normal "-STOP" (-15) doesn't work. May be this is somewhat related to the "save-file problem". [/QUOTE] It seems that the Linux version can be stopped by pressing <Ctrl><C> or the "kill -15" command, but usually it doesn't stop immediately. It may take a few seconds to half a minute until it stops. And restarting seems to work with the Linux version too, but it may also take up to a minute for reading the zXXXXXXX file. So for stopping and restarting we need a bit more patience :sleep: Since I haven't tested the Windows version so far, someone else may test this behaviour again and see if restarting works there too ... -- Thomas. |
[QUOTE=Thomas11]Since I haven't tested the Windows version so far, someone else may test this behaviour again and see if restarting works there too ...
-- Thomas.[/QUOTE] 45" to stop, 120" for the icon to turn green... but after 360" no updating message appeared. I'm afraid I'll have to cancel my zXXXX file again :sad: On the other hand, changing priority seems to take place immediately. Luigi |
THe screen output for my range is all screwed up. Another thing for Jean to fix.
Citrix :cool: :cool: :cool: |
[QUOTE=ET_] ... On the other hand, changing priority seems to take place immediately.[/QUOTE]What about bumping the priority to maximum, and then stopping it. Would that help?
Bruce |
is LLR working right?
Is LLR working right?
I am using a Pentium III 600 Mhz. For PRP, when I test the Riesel number: 465*2^300000-1, it has a per iteration time of around 7.6 ms. However, when I use this new LLR, it has a per iteration time of around 6.3 ms. Is there something wrong? regards, william Edit: here is the llrresults file: [Sat Mar 27 06:32:50 2004] Using IBDWT : Mersenne fftlen = 14336, Proth fftlen = 28672, Used fftlen = 28672 |
Jean wrote Yahoo! primenumbers:
[QUOTE]So, this program uses IBDWT only if k <= 511 in non SSE2 code, and (alas...) k <= 31 in SSE2 code ; for larger k's, it works exactly like the previous LLR version, using Proth mode and rational bases FFT. But for really small k's, it is a major improvement: [/QUOTE] So it is very small k <=31 on a SSE2 P4 that get's the maximum boost of about 400% |
[QUOTE]this program uses IBDWT only if k <= 511 in non SSE2 code[/QUOTE]
I wonder if Jean meant less than 256 which is 2^8 ... :unsure: |
[QUOTE=Maybeso]What about bumping the priority to maximum, and then stopping it. Would that help?
Bruce[/QUOTE] No it wouldn't. The prorgam seems to start correctly, but the first iteration count comes out after 2-4 minutes. :sad: Luigi |
Just one short note:
It seems that the "+016" bug happens under Windows only. I've tested some low n-values for k=5 and k=7 twice on a Athlon runing Windows and on a P4 running Linux. I've got some "+016" results on the Athlon/Windows but not on the P4/Linux. As Paul already noted, the Res64 values are the same, so I expect it to be a bug in the screen/file output routine and not in the entire calculation. Well, from the above I could also conclude that it is a problem of the Athlon. But I guess, that most of you, who encountered the same problem, are using P4 machines running some version of Windows ... -- Thomas. P.S.: Tomorrow my machine(s) will take an out-time, since due to maintenance work we will be out of electrical power the whole day. So, don't expect any new primes from my end for tomorrow :yawn: |
next version LLR
Next version of LLR released with few bug fixes.
[url]http://groups.yahoo.com/group/primenumbers[/url] regards, william |
Thanks for the link William.
I am still having problems with "stop/continue" and starting LLR if a "save file" exists. A save file is created when you shutdown Windoze. I get around the problem by making sure no "save files" exist by use of the following dos batch file in C:\WINDOWS\Start Menu\Programs\StartUp\llr.bat cd \paul\llr -- this will be different for you del y*.* del z*.* llr.exe exit Jean Penne assure me that "stop/continue" does work after a time -- but to me it seems an inordinate amount of time! |
[QUOTE=wfgarnett3]Next version of LLR released with few bug fixes.
[url]http://groups.yahoo.com/group/primenumbers[/url] regards, william[/QUOTE] Waiting to download it from GIMPS :rolleyes: Luigi |
Jean Penne is about make available the very latest LLR ( based on George Woltman's latest IBDWT library?) [URL=http://groups.yahoo.com/group/primenumbers/message/15182]see here[/URL] Also keep a look over the next few days for the new program at [URL=http://www.mersenne.org/gimps/]http://www.mersenne.org/gimps/[/URL] Jean claims to have fixed the stop/continue bug... :cool:
Big thanks to Jean and George :bow: :bow: :bow: |
All bow down to the great creators!!!!
:bow: :bow: :bow: :bow: :bow: :bow: |
Fine!
I'll download it as soon as it is released! Luigi |
[QUOTE=ET_]I'll download it as soon as it is released![/QUOTE]
It is already available in the files section of [url]http://groups.yahoo.com/group/primenumbers[/url] Under the section "Files > ProvingPrograms" there are three files. One for Windows and two for Linux. |
[QUOTE=BotXXX]It is already available in the files section of [url]http://groups.yahoo.com/group/primenumbers[/url]
Under the section "Files > ProvingPrograms" there are three files. One for Windows and two for Linux.[/QUOTE] So I'll wait until someone will upload the files on mersenne.org/gimps :help: Luigi |
Wait a little more and we will see "llr3" (or whatever it will be called) which is 30% faster than llr2 because it is based on George's latest IBDWT library. :shock:
|
[QUOTE=paulunderwood]Wait a little more and we will see "llr3" (or whatever it will be called) which is 30% faster than llr2 because it is based on George's latest IBDWT library. :shock:[/QUOTE]
Sure I will! Thank you! :bow: Luigi |
Latest binaries can be found by following the links [URL=http://groups.yahoo.com/group/primenumbers/message/15184]here[/URL]
Happy hunting :devil: |
I Just downloaded and tried the new LLR4P. It works great!!!
Start and Stop easily. On my machine it is 3 times faster. at n=800,000 on k=253. thank you so much. :grin: Joss |
On my NON-SSE2 box, the new LLR was much slower. I notice that it tends to select the largest FFT (for N around 700,000) so it took twice the time that the old LLR would have for that number.
|
[QUOTE=justinsane]On my NON-SSE2 box, the new LLR was much slower. I notice that it tends to select the largest FFT (for N around 700,000) so it took twice the time that the old LLR would have for that number.[/QUOTE]
You are testing k=121, right? And around n=700,000 (or may be n=730,000) I would expect a lot of fftlen switching with the old LLR, isn't it? The new formula for choosing the FFT length works well for k<32 but tends to overestimate at larger values of k. There is still no "optimal" formulation for guessing the FFT length right. If on your k the new non-SSE2 LLR is slower than the old one, then I suggest the use the old LLR. -- Thomas |
[QUOTE=Thomas11]You are testing k=121, right? And around n=700,000 (or may be n=730,000) I would expect a lot of fftlen switching with the old LLR, isn't it?
The new formula for choosing the FFT length works well for k<32 but tends to overestimate at larger values of k. There is still no "optimal" formulation for guessing the FFT length right. If on your k the new non-SSE2 LLR is slower than the old one, then I suggest the use the old LLR. -- Thomas[/QUOTE] I've stuck with the old one for now on this machine. Even for large N, like 121, the SSE2 version is still much faster. |
timings
Thomas Ritschel sent me some LLR timings for 321search on his AMD Opteron computer . These show where the FFT sizes change. This is where we notice a slow down in iteration timings and the LLR tests taking longer.
Opteron 2GHz ------------ n Mers. Proth used t/iter. ------------------------------------------ 1200000 65536 131072 65536 3.035 ms 1273062 65536 131072 65536 3.035 ms * 1273063 65536 131072 81920 4.055 ms * 1300000 65536 131072 81920 4.055 ms 1400000 81920 163840 81920 4.055 ms 1500000 81920 163840 81920 4.055 ms 1583078 81920 163840 81920 4.055 ms * 1583079 81920 163840 98304 5.145 ms * 1600000 81920 163840 98304 5.145 ms 1700000 98304 196608 98304 5.145 ms 1800000 98304 196608 98304 5.145 ms 1888094 98304 196608 98304 5.145 ms * 1888095 98304 196608 114688 6.350 ms * 1900000 98304 196608 114688 6.350 ms 2000000 114688 229376 114688 6.350 ms 2100000 114688 229376 114688 6.350 ms 2196110 114688 229376 114688 6.350 ms * 2196111 114688 229376 131072 7.285 ms * 2200000 114688 229376 131072 7.285 ms 2300000 131072 262144 131072 7.285 ms 2400000 131072 262144 131072 7.285 ms 2500000 131072 262144 131072 7.285 ms 2510126 131072 262144 131072 7.285 ms * 2510127 131072 262144 163840 9.385 ms * 2600000 131072 262144 163840 9.385 ms 2700000 163840 327680 163840 9.385 ms 2800000 163840 327680 163840 9.385 ms 2900000 163840 327680 163840 9.385 ms 3000000 163840 327680 163840 9.385 ms 3100000 163840 327680 163840 9.385 ms 3121158 163840 327680 163840 9.385 ms * 3121159 163840 327680 196608 11.195 ms * 3200000 163840 327680 196608 11.195 ms 3300000 196608 393216 196608 11.195 ms 3400000 196608 393216 196608 11.195 ms 3500000 196608 393216 196608 11.195 ms 3600000 196608 393216 196608 11.195 ms 3700000 196608 393216 196608 11.195 ms 3719190 196608 393216 196608 11.195 ms * 3719191 196608 393216 229376 13.490 ms * 3800000 196608 458752 229376 13.490 ms 3900000 229376 458752 229376 13.490 ms 4000000 229376 458752 229376 13.490 ms 4100000 229376 458752 229376 13.490 ms 4200000 229376 458752 229376 13.490 ms 4300000 229376 458752 229376 13.490 ms 4330220 229376 458752 229376 13.490 ms * 4330223 229376 458752 262144 15.085 ms * 4400000 229376 524288 262144 15.085 ms 4500000 229376 524288 262144 15.085 ms 4600000 262144 524288 262144 15.085 ms 4700000 262144 524288 262144 15.085 ms 4800000 262144 524288 262144 15.085 ms 4900000 262144 524288 262144 15.085 ms 4950254 262144 524288 262144 15.085 ms * 4950255 262144 524288 327680 20.395 ms * 5000000 262144 655360 327680 20.395 ms |
Thomas Ritschel pointed out to me that the FFT size change occurs at different "n" for Athlons than P4s. When we get to the difference in a couple of months it makes sense to have "Athlon only 321 files". The first set of files that should be tested by Athlons only is:
[B]1888000-1926000[/B] The complete table for [B]Athlons[/B] is: Athlon 2GHz ----------- n Mers. used t/iter. ---------------------------------- 1200000 65536 65536 3.660 ms 1299062 65536 65536 3.660 ms * 1299063 65536 81920 4.720 ms * (+26000) 1300000 65536 81920 4.720 ms 1400000 81920 81920 4.720 ms 1500000 81920 81920 4.720 ms 1600000 81920 81920 4.720 ms 1610078 81920 81920 4.720 ms * 1610079 98304 98304 5.825 ms * (+27000) 1700000 98304 98304 5.825 ms 1800000 98304 98304 5.825 ms 1900000 98304 98304 5.825 ms 1925094 98304 98304 5.825 ms * 1925095 98304 114688 6.980 ms * (+37000) 2000000 98304 114688 6.980 ms 2100000 114688 114688 6.980 ms 2200000 114688 114688 6.980 ms 2244110 114688 114688 6.980 ms * 2244111 131072 131072 7.840 ms * (+48000) 2300000 131072 131072 7.840 ms 2400000 131072 131072 7.840 ms 2500000 131072 131072 7.840 ms 2560126 131072 131072 7.840 ms * 2560127 131072 163840 10.020 ms * (+50000) 2600000 131072 163840 10.020 ms 2700000 163840 163840 10.020 ms 2800000 163840 163840 10.020 ms 2900000 163840 163840 10.020 ms 3000000 163840 163840 10.020 ms 3100000 163840 163840 10.020 ms 3171158 163840 163840 10.020 ms * 3171159 163840 196608 11.950 ms * (+50000) 3200000 163840 196608 11.950 ms 3300000 163840 196608 11.950 ms 3400000 196608 196608 11.950 ms 3500000 196608 196608 11.950 ms 3600000 196608 196608 11.950 ms 3700000 196608 196608 11.950 ms 3789190 196608 196608 11.950 ms * 3789191 196608 229376 14.450 ms * (+70000) 3800000 196608 229376 14.450 ms 3900000 196608 229376 14.450 ms 4000000 229376 229376 14.450 ms 4100000 229376 229376 14.450 ms 4200000 229376 229376 14.450 ms 4300000 229376 229376 14.450 ms 4400000 229376 229376 14.450 ms 4420220 229376 229376 14.450 ms * 4420223 229376 262144 15.880 ms * (+90000) 4500000 229376 262144 15.880 ms 4600000 229376 262144 15.880 ms 4700000 262144 262144 15.880 ms 4800000 262144 262144 15.880 ms 4900000 262144 262144 15.880 ms 5000000 262144 262144 15.880 ms |
Thomas informs me that the FFT boundaries have changed recently with the latest LLRs for Athlons:
Here are the latest Athlon FFT lengths for k=3: fftlen nmax ----------------------- 114688 2233110 131072 2560126 163840 3180158 196608 3777190 229376 4411222 262144 5056254 ----------------------- So it makes sense to use a older version of LLR to do n=2233111-2244110 :shock: This would be about 600 tests, saving 2000 secs per test = 2 cpu weeks :banana: We'll sort it out when the next set of numbers are released (n>2.2 million) Thanks Thomas :bow: |
Meanwhile I had some additional tests on the Athlon, using LLR 3.5, 3.6, and 3.6.2.
As Paul already mentioned in the above post, the FFT boundaries are slightly lower for the latest LLR versions (3.6 and 3.6.2), e.g. for the current 112k FFT we have nmax=2233110 for versions 3.6/3.6.2, but nmax=2244110 for version 3.5. Below are some timings using the different LLR's on my 2GHz Athlon: [CODE]Athlon 2GHz (2400+) -------------------- times per iteration for FFT lengths 114688 (112k) and 131072 (128k): LLR 112k 128k ---------------------- 3.5 7.024 7.904 3.6 7.045 7.938 3.6.2 7.042 7.944 ----------------------[/CODE] We note the following: (1) There is no significant difference between LLR 3.6 and 3.6.2. (2) LLR 3.5 is slightly faster than 3.6/3.6.2 (about 0.3-0.5%). The latter holds only for the Athlon. On the P4, versions 3.6/3.6.2 are about 1.5-2% faster than LLR 3.5 (at least on my machines...). If someone else (perhaps, or at least you, Paul :help: ) would verify that LLR 3.5 is still a bit faster (or at least not slower) than versions 3.6/3.6.2 on your Athlons, we could recommend to use LLR 3.5 exclusively and entirely for the Athlon, e.g. not only for n=2233111-2244110, but for any range. For those of you, who want to do the timings, I suggest to use the following n's: 2233110 and 2233111, or 2244110 and 2244111, depending on the LLR version. Set the screen output to "every 1000 iterations" and watch it for about one minute. Note, that the very first output on your screen shows a larger msecs/iteration due to the initial U0/V0 computations. And now let's find that two-megabit prime! :bounce: |
I have timed "llr35" and "llr362" on an Athlon (Debian+X) and calculated that the old LLR is 0.4% quicker:
7.912 ms/iteration llr362 7.880 ms/iteration llr35 :confused: |
Some more timings on Linux with no X:
Athlon 1050MHz 13.014 ms/iteration llr362 13.028 ms/iteration llr35 ...new LLR slightly faster (0.1%) Athlon XP1600+ 9.432 ms/iteration llr362 9.401 ms/iteration llr35 ...old LLR faster (0.3%) Athlon XP2000+ 8.278 ms/iteration llr362 8.250 ms/iteration llr35 ...old LLR faster (0.3%) So it seems on AthlonXPs (not ordinary old Athlons) it is better to run LLR35 :lol: |
Just out of curiosity I did a test on an Opteron 246 (2 GHz) using the "CpuSupportsSSE2=0" switch to see whether it would run faster at the lower FFT length. Here are the figures I got:
[CODE] FFT length time per iteration --------------------------------------------- SSE2 enabled: 196608 8.483 ms SSE2 disabled: 163840 9.036 ms[/CODE] It clearly shows that the SSE2 code is much faster, even at the higher FFT length. This behaviour should also hold for the Athlon64's. Perhaps someone could do a test for verification... |
IBDWT break points for 5M < n < 20M+
Thanks to Thomas for this info:
here are the FFT lengths and break points for k=3, n=5-20M: [CODE]For P4 and other SSE2 cpus: fftlen nmax ----------------------- 327680 6161318 393216 7339382 458752 8544446 524288 9764510 655360 12130637 786432 14446765 917504 16822893 1048576 19219021 1310720 23891277 And for Athlons (cpus without SSE2): fftlen nmax ----------------------- 262144 5056254 327680 6285318 393216 7460382 458752 8707446 524288 9964510 655360 12370637 786432 14686765 917504 17162893 1048576 19629021 1310720 24351277[/CODE] |
1 Attachment(s)
By request and by curtesy of Thomas here is the program to create tables such as above.
[QUOTE]The attached zip file contains the little tool "fft_len" which I used to get those numbers. You simply need to rename/copy the file matching your cpu architecture (either "maxlen_Athlon.txt" or "maxlen_P4.txt") to "maxlen.txt" and then run fft_len from the command line. It asks for "k", "n_min" and "n_max" and then produces the list.[/QUOTE] |
1 Attachment(s)
Here is another program written by Thomas for optimization of project throughput, for wide ranges of "n" crossing FFT jumps. :smile:
|
| All times are UTC. The time now is 20:00. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2022, Jelsoft Enterprises Ltd.