LLR development version 3.8.7 is available! - Page 4

Jean Penné · 2012-03-29, 20:34

Quote:

Originally Posted by Jeff Gilchrist

Jean, I just wanted to say merci for the latest release using GWNUM that supports AVX code. I have seen an enormous speedup for Vrba-Reix tests using a 480K FFT length. With LLR 3.8.7 I was getting an average of 62500 seconds per test and with 3.8.8 this has decreased to 37500 seconds!

Jeff.

Hi Jeff,
I am very glad to learn about this speedup in your tests.
But it is above all to George Woltman we have to say a great "Thank You" for the work he is doing since 1996 to improve his large integer computing code!
Almost each new release of his gwnum library yields an important progress.

Regards,
Jean

paulunderwood · 2012-03-29, 21:35

Quote:

Originally Posted by Jean Penné

It is surprising! I have exactly the same Debian Linux system as you, and I have not this restart problem with your sample test...
(But I had it with the "externally built" binary!)

What CPU have you? It seems to be only hardware dependant...
Jean

I have been testing on is a Intel Q6600. I have just tried sllr64 and llr64 on an AMD 1090T and it suffers from the same problem

Here is the llr.ini from the test on the Q6600:

Code:

Work=0
PgenInputFile=llr_in
PgenOutputFile=
PgenLine=1
WorkDone=0
NoPrefactoring=1 
VrbaReixTest=1 
Pid=9715
HeaderLine=0
ResultLine=1

I notice that the Pid is non-zero

The input file is:

Quote:

ABC (2^$a+1)/3
83339
986191

I had been using ia32-libs for llr (32 bit) before llr64 was released. I removed it but the problem persists.

Here is the md5sum I get for llr64

Code:

36c15c447b03a076854ddc7dd046d479  llr64

Thomas11 · 2012-03-30, 08:35

I tested Paul's input file on a Q6600 machine (llr64 3.8.8 on openSuSE 12.1).

While I wasn't able to reproduce the segmentation fault, I noticed another problem:
If the first test in the file is interrupted and restarted it yields the following result:

Code:

(2^83339+1)/3 is not prime.  Vrba-Reix RES64: FE5155C7E615DA33  Time : 6.097 sec

Uninterrupted it yields:

Code:

(2^83339+1)/3 is Vrba-Reix PRP!  Time : 4.988 sec.

I tried this again on a different machine (Xeon X5675) and got the same behavior, however with a different RES64:

Code:

(2^83339+1)/3 is not prime.  Vrba-Reix RES64: 74C74F69233C5F6F  Time : 3.198 sec

Jean Penné · 2012-03-30, 13:35

Quote:

Originally Posted by Thomas11

I tested Paul's input file on a Q6600 machine (llr64 3.8.8 on openSuSE 12.1).

While I wasn't able to reproduce the segmentation fault, I noticed another problem:
If the first test in the file is interrupted and restarted it yields the following result:

Code:

(2^83339+1)/3 is not prime.  Vrba-Reix RES64: FE5155C7E615DA33  Time : 6.097 sec

Uninterrupted it yields:

Code:

(2^83339+1)/3 is Vrba-Reix PRP!  Time : 4.988 sec.

I tried this again on a different machine (Xeon X5675) and got the same behavior, however with a different RES64:

Code:

(2^83339+1)/3 is not prime.  Vrba-Reix RES64: 74C74F69233C5F6F  Time : 3.198 sec

I can now reproduce this problem at home ; so the bug is not presently fixed.
It is bound to Linux llr64 and stopping/restarting a Wagstaff job...
I will search further to fix it...
Regards,
Jean

Jeff Gilchrist · 2012-03-30, 15:00

Quote:

Originally Posted by Jean Penné

I can now reproduce this problem at home ; so the bug is not presently fixed.
It is bound to Linux llr64 and stopping/restarting a Wagstaff job...
I will search further to fix it...

I just tested this case with the 64bit Windows binary of v3.8.8 for LLR.exe and cllr64.exe. All cases give the proper PRP result, if you are stopping/restarting or not so it seems Windows is ok.

I did find a bug in cllr64.exe though. Once the list of exponents is finished, cllr64.exe will crash. It looks like it is crashing when it is trying to update the llr.ini file as it never gets updated.

Also looking at the 64bit Linux version of LLR 3.8.5 is also ok, stopping/restarting seems to work ok with the test case mentioned above.

Jeff.

diep · 2012-03-30, 16:21

Quote:

Originally Posted by Jean Penné

I can now reproduce this problem at home ; so the bug is not presently fixed.
It is bound to Linux llr64 and stopping/restarting a Wagstaff job...
I will search further to fix it...
Regards,
Jean

We have big faith in you Jean!

pepi37 · 2012-04-27, 12:33

Is new cllr 3.8.9 on the way?

2012-03-30, 08:35	#36
Thomas11 Feb 2003 2²·3²·53 Posts	I tested Paul's input file on a Q6600 machine (llr64 3.8.8 on openSuSE 12.1). While I wasn't able to reproduce the segmentation fault, I noticed another problem: If the first test in the file is interrupted and restarted it yields the following result: Code: (2^83339+1)/3 is not prime. Vrba-Reix RES64: FE5155C7E615DA33 Time : 6.097 sec Uninterrupted it yields: Code: (2^83339+1)/3 is Vrba-Reix PRP! Time : 4.988 sec. I tried this again on a different machine (Xeon X5675) and got the same behavior, however with a different RES64: Code: (2^83339+1)/3 is not prime. Vrba-Reix RES64: 74C74F69233C5F6F Time : 3.198 sec Last fiddled with by Thomas11 on 2012-03-30 at 08:39

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
LLR Development Version 3.8.9 released.	Jean Penné	Software	6	2012-05-09 23:44
LLR 3.8.6 Development version	Jean Penné	Software	0	2011-06-16 20:05
LLR 3.8.5 Development version	Jean Penné	Software	6	2011-04-28 06:21
PowerPC development platform	nuggetprime	Hardware	2	2011-01-06 18:37
LLR 3.8.4 development version is available!	Jean Penné	Software	4	2010-11-14 17:32

2012-04-27, 12:33	#40
pepi37 Dec 2011 After milion nines:) 5×17² Posts	Is new cllr 3.8.9 on the way?