mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   3*2^n-1 Search (https://www.mersenneforum.org/forumdisplay.php?f=14)
-   -   DWT (https://www.mersenneforum.org/showthread.php?t=620)

paulunderwood 2003-05-31 03:38

DWT
 
I found this:

[url]http://groups.yahoo.com/group/primenumbers/message/7510[/url]

How long before an implementation :question:

b2lee 2004-03-21 06:05

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.

ET_ 2004-03-21 19:42

[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

paulunderwood 2004-03-21 20:20

[QUOTE]I just can't WAIT!!![/QUOTE]

Me too :smile: :smile: :smile:

To JP: :bow:

wfgarnett3 2004-03-24 10:21

New LLR ready!!!
 
Title says it all.

[url]http://groups.yahoo.com/group/primenumbers/[/url]

Nice job Jean!!!

regards,
william

ET_ 2004-03-24 11:25

[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

paulunderwood 2004-03-24 11:49

I have asked xyzzy to host it at primerib -- this will happen soon!

The gimps directory should also contain it soon!

Thomas11 2004-03-24 18:44

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.

paulunderwood 2004-03-25 02:41

[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:

ET_ 2004-03-25 12:04

[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

Citrix 2004-03-25 14:37

[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:

paulunderwood 2004-03-25 15:23

[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...

Citrix 2004-03-25 16:57

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:

paulunderwood 2004-03-25 18:02

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:

Prime95 2004-03-25 18:22

The source is now at [url]ftp://mersenne.org/llrsrc23.tgz[/url]

MrHappy 2004-03-25 18:47

[QUOTE=Prime95]The source is now at [url]ftp://mersenne.org/llrsrc23.tgz[/url][/QUOTE]
[url]ftp://mersenne.org/gimps/llrsrc23.tgz[/url]... :wink:

ET_ 2004-03-25 20:12

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

paulunderwood 2004-03-25 20:57

Book it and grab it [URL=http://www.mersenneforum.org/showthread.php?t=1545]here[/URL]

Thomas11 2004-03-26 14:09

[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.

ET_ 2004-03-26 14:25

[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

Citrix 2004-03-26 14:46

THe screen output for my range is all screwed up. Another thing for Jean to fix.

Citrix
:cool: :cool: :cool:

Maybeso 2004-03-27 09:29

[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

wfgarnett3 2004-03-27 11:34

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

paulunderwood 2004-03-27 12:24

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%

paulunderwood 2004-03-27 12:49

[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:

ET_ 2004-03-27 16:54

[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

Thomas11 2004-03-31 18:25

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:

wfgarnett3 2004-04-12 03:21

next version LLR
 
Next version of LLR released with few bug fixes.
[url]http://groups.yahoo.com/group/primenumbers[/url]

regards,
william

paulunderwood 2004-04-12 11:37

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!

ET_ 2004-04-12 11:55

[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

paulunderwood 2004-08-01 22:24

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:

Lupine1647 2004-08-01 22:55

All bow down to the great creators!!!!

:bow: :bow: :bow: :bow: :bow: :bow:

ET_ 2004-08-02 11:51

Fine!

I'll download it as soon as it is released!

Luigi

BotXXX 2004-08-02 11:57

[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.

ET_ 2004-08-02 12:55

[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

paulunderwood 2004-08-02 13:09

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:

ET_ 2004-08-02 13:31

[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

paulunderwood 2004-08-02 18:10

Latest binaries can be found by following the links [URL=http://groups.yahoo.com/group/primenumbers/message/15184]here[/URL]

Happy hunting :devil:

jocelynl 2004-08-02 21:01

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

justinsane 2004-08-02 23:26

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.

Thomas11 2004-08-03 08:29

[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

justinsane 2004-08-04 03:46

[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.

paulunderwood 2004-09-05 08:56

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

paulunderwood 2005-03-22 17:22

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

paulunderwood 2005-10-07 15:15

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:

Thomas11 2005-10-08 14:38

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:

paulunderwood 2005-10-08 23:52

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:

paulunderwood 2005-10-09 00:28

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:

Thomas11 2007-02-14 10:17

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...

paulunderwood 2008-06-16 17:32

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]

paulunderwood 2008-06-26 14:17

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]

paulunderwood 2008-06-26 15:56

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.