P4 SSE2 routine bug?

2003-07-13, 00:24

Our 15k search has run into a small problem with false negatives.
Here is my correspondence with Thomas Ritschel.

>Hmm, I get 50, I hope its not the GIMPS false positive bug?
>>"From intuition I would start to count from n=29/30,
>>since 290499495<2^29 and 904522905<2^30. Please tell me, if I'm >>wrong."
>>>Thats what I used, the first available 5000 n, holding a Riesel definition.
290499495 2^29
n=29
290499495 31
290499495 34
290499495 36
290499495 41
290499495 44
290499495 48
290499495 50
290499495 57
290499495 65
290499495 66
290499495 74
290499495 93
290499495 136
290499495 145
290499495 183
290499495 188
290499495 275
290499495 364
290499495 386
290499495 448
290499495 479
290499495 554
290499495 556
290499495 560
290499495 626
290499495 691
290499495 726
290499495 757
290499495 923
290499495 964
290499495 1062
290499495 1081
290499495 1233
290499495 1310
290499495 1468
290499495 1560
290499495 1636
290499495 2056
290499495 2079
290499495 2511
290499495 2630
290499495 3362
290499495 3494
290499495 3625
290499495 3897
290499495 4223
290499495 4263
290499495 4460
290499495 4592
290499495 4885 =50 not 56
n=5029

n=30
904522905 36
904522905 40
904522905 60
904522905 69
904522905 96
904522905 128
904522905 156
904522905 162
904522905 205
904522905 222
904522905 290
904522905 306
904522905 312
904522905 361
904522905 366
904522905 368
904522905 452
904522905 600
904522905 672
904522905 677
904522905 777
904522905 847
904522905 886
904522905 953
904522905 1152
904522905 1313
904522905 1413
904522905 1488
904522905 1511
904522905 1689
904522905 1790
904522905 1895
904522905 1965
904522905 1982
904522905 2104
904522905 2120
904522905 2200
904522905 2366
904522905 2415
904522905 2728
904522905 2748
904522905 2845
904522905 3502
904522905 3572
904522905 3581
904522905 3621
904522905 3819
904522905 3854
904522905 4128
904522905 4550
904522905 4560
904522905 5019 =52
5030
____________________________________________
From Thomas
Hi Shane,
> Hmm, I get 50, I hope its not the GIMPS false positive bug?
Well, I get all the primes you have listed, but a few more!
The following numbers are prime too:
290499495 77
290499495 84
290499495 87
____________
290499495 103
290499495 108
290499495 109
and:
904522905 80
904522905 89
____________
904522905 106
904522905 122

I've got them on my Athlon with LLR and verified the results on a PIII
machine with Yves Gallots Proth. On my P4/Xeon machine LLR stops in
most cases for n<128 with a memory allocation error. But I got it to do
the following:

290499495*2^106-1 is not prime. Res64: AE1F17451CD8E001
290499495*2^109-1 is not prime. Res64: B37A1C79DED7B002

It seems to be a problem on the P4 only. And PRP shows the same
behaviour, so it may be an intrinsic problem of the SSE2 routines.

Interesting is the fact that the primes 290499495*2^93-1 and
904522905*96-1 are found anyway! (Therefore the gaps in the above lists)

After all it seems to be a problem for small n only (n<128). So our
other work may not be effected. But we should inform Jean Penne and/or
George Woltman about that problem.
Cheers,
Thomas.
__________________________________

The problem does not give me any errors, so LLR is giving false negatives without any warning. I am worried that it has effected some of our work. We should do some double testing with athlon's to insure a low probability.

2003-07-13, 00:44

I have checked to make sure this is not a NewGpen problem.

I have now reproduced this same exact glitch on four P4's.
Two athlon's show the missing 10 primes
No errors occured at all.

This could change how we think of Athlon's versus Intel, for Prime95 and LLR.

Please help explain this George or Jean.

ebx · 2003-07-13, 02:42

I reproduced the same on my p4 2.26/Win2K and XP1900+/WinXP.

Does anybody have a Opteron so we can see how AMD does SSE2?

Prime95 · 2003-07-13, 03:47

I just tested these 6 with PRP.EXE dated July 26, 2002. All were found probable prime on my P4. Please give me more details so that I can reproduce the problem here.

290499495 77
290499495 84
290499495 87
290499495 103
290499495 108
290499495 109

ebx · 2003-07-13, 04:13

Problem found with LLR. Sieved done by NewPGen.

2003-07-13, 04:30

Quote:

I just tested these 6 with PRP.EXE dated July 26, 2002. All were found probable prime on my P4. Please give me more details so that I can reproduce the problem here.

I'm not sure how more specific the details can be, without programming knowledge but, I have reproduced it identically on two more P4's, with no errors. Newgpen, shows these numbers on the text file.

Was there an early version of LLR? Try that.
Is there a way to cancel SSE2? To rule that out.
Maybe it's just a small n problem, but we will see soon.
I am crossing my fingers on this one.

Prime95 · 2003-07-13, 05:58

Quote:

Originally Posted by TTn

I'm not sure how more specific the details can be,

Was there an early version of LLR? Try that.
Is there a way to cancel SSE2? To rule that out.
Maybe it's just a small n problem, but we will see soon.
I am crossing my fingers on this one.

Someone mentioned they could also reproduce the problem with PRP. If so, I can use that to debug the SSE2 routines.

I didn't write LLR so I'd rather wait for LLR's author to look into the problem if the bug only happens in LLR.

2003-07-13, 12:53

I have informed Jean of the problem.
Thomas did seem to say that PRP had the same behavior.

Please try these k & n, with the old PRP and LLR.
504017085(n=104,117,126,133,605,649...?)
509070705(n=79,86,107,112,117,586...?)
515179665(n=76,80,85,110,118,123,126...?)
These test are supposed to be deterministic!
When a probable program gets better results, it is rather dissheartening.

Bad news,
I have doublechecked thirty k, with small values n<5000
All with these false negatives, which seem to appear on any line, and are gapped sporatically. No easily noticable pattern other than a sharp drop.

Good news,
I have doublechecked three k, with large values n<30000
and found no false negatives.

Although I am still not satisfyed, that the falsees are more sparce with large n.
Because they could decide to cluster in the area we just happen to be testing.

nitro · 2003-07-13, 17:09

Quote:

Originally Posted by TTn

Our 15k search has run into a small problem with false negatives.
[snip]

On my P4/Xeon machine LLR stops in most cases for n<128 with a memory allocation error.

So you get a memory allocation error and your first instinct is that the cpu has a hard-coded failure rather than the fact that the software or compiler screwed up?????

dswanson · 2003-07-13, 19:12

I think TTn's logic for thinking it's the CPU is that the problem occurs on P4's, but not on AMDs or older Pentium series.

ebx · 2003-07-13, 19:36

You need to read the problem and problem description more carefully.

The title of this thread is 'P4 SSE2 routine bug?'. That does sound like a software problem to me although it is not impossible that there are underlaying hardware bugs.

Memory allocation is an issue of itself. It occurred but didnt contribute to the SSE2 bug reported.

Maybe it was one of my posts that lead to the think of a hardware bug.

2003-07-13, 00:24	#1
TTn 2³·53 Posts	P4 SSE2 routine bug? Our 15k search has run into a small problem with false negatives. Here is my correspondence with Thomas Ritschel. >Hmm, I get 50, I hope its not the GIMPS false positive bug? >>"From intuition I would start to count from n=29/30, >>since 290499495<2^29 and 904522905<2^30. Please tell me, if I'm >>wrong." >>>Thats what I used, the first available 5000 n, holding a Riesel definition. 290499495 2^29 n=29 290499495 31 290499495 34 290499495 36 290499495 41 290499495 44 290499495 48 290499495 50 290499495 57 290499495 65 290499495 66 290499495 74 290499495 93 290499495 136 290499495 145 290499495 183 290499495 188 290499495 275 290499495 364 290499495 386 290499495 448 290499495 479 290499495 554 290499495 556 290499495 560 290499495 626 290499495 691 290499495 726 290499495 757 290499495 923 290499495 964 290499495 1062 290499495 1081 290499495 1233 290499495 1310 290499495 1468 290499495 1560 290499495 1636 290499495 2056 290499495 2079 290499495 2511 290499495 2630 290499495 3362 290499495 3494 290499495 3625 290499495 3897 290499495 4223 290499495 4263 290499495 4460 290499495 4592 290499495 4885 =50 not 56 n=5029 n=30 904522905 36 904522905 40 904522905 60 904522905 69 904522905 96 904522905 128 904522905 156 904522905 162 904522905 205 904522905 222 904522905 290 904522905 306 904522905 312 904522905 361 904522905 366 904522905 368 904522905 452 904522905 600 904522905 672 904522905 677 904522905 777 904522905 847 904522905 886 904522905 953 904522905 1152 904522905 1313 904522905 1413 904522905 1488 904522905 1511 904522905 1689 904522905 1790 904522905 1895 904522905 1965 904522905 1982 904522905 2104 904522905 2120 904522905 2200 904522905 2366 904522905 2415 904522905 2728 904522905 2748 904522905 2845 904522905 3502 904522905 3572 904522905 3581 904522905 3621 904522905 3819 904522905 3854 904522905 4128 904522905 4550 904522905 4560 904522905 5019 =52 5030 ____________________________________________ From Thomas Hi Shane, > Hmm, I get 50, I hope its not the GIMPS false positive bug? Well, I get all the primes you have listed, but a few more! The following numbers are prime too: 290499495 77 290499495 84 290499495 87 ____________ 290499495 103 290499495 108 290499495 109 and: 904522905 80 904522905 89 ____________ 904522905 106 904522905 122 I've got them on my Athlon with LLR and verified the results on a PIII machine with Yves Gallots Proth. On my P4/Xeon machine LLR stops in most cases for n<128 with a memory allocation error. But I got it to do the following: 2904994952^106-1 is not prime. Res64: AE1F17451CD8E001 2904994952^109-1 is not prime. Res64: B37A1C79DED7B002 It seems to be a problem on the P4 only. And PRP shows the same behaviour, so it may be an intrinsic problem of the SSE2 routines. Interesting is the fact that the primes 2904994952^93-1 and 90452290596-1 are found anyway! (Therefore the gaps in the above lists) After all it seems to be a problem for small n only (n<128). So our other work may not be effected. But we should inform Jean Penne and/or George Woltman about that problem. Cheers, Thomas. __________________________________ The problem does not give me any errors, so LLR is giving false negatives without any warning. I am worried that it has effected some of our work. We should do some double testing with athlon's to insure a low probability.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Two routine results	Raman	Data	16	2011-01-03 06:35
Training for your multi-precision division routine	fivemack	Puzzles	3	2007-04-26 17:01
RSA and SSE2	Cyclamen Persicum	Math	5	2003-11-10 07:41
Is TF from 2^64 to 2^65 using SSE2?	TauCeti	Software	3	2003-10-17 06:30
SSE2 ?	TauCeti	NFSNET Discussion	8	2003-06-30 12:58

2003-07-13, 00:44	#2
TTn 2×5×7×73 Posts	I have checked to make sure this is not a NewGpen problem. I have now reproduced this same exact glitch on four P4's. Two athlon's show the missing 10 primes No errors occured at all. This could change how we think of Athlon's versus Intel, for Prime95 and LLR. Please help explain this George or Jean.

2003-07-13, 02:42	#3
ebx Aug 2002 101 Posts	I reproduced the same on my p4 2.26/Win2K and XP1900+/WinXP. Does anybody have a Opteron so we can see how AMD does SSE2?

2003-07-13, 03:47	#4
Prime95 P90 years forever! Aug 2002 Yeehaw, FL 2·53·71 Posts	I just tested these 6 with PRP.EXE dated July 26, 2002. All were found probable prime on my P4. Please give me more details so that I can reproduce the problem here. 290499495 77 290499495 84 290499495 87 290499495 103 290499495 108 290499495 109

2003-07-13, 04:13	#5
ebx Aug 2002 145₈ Posts	Problem found with LLR. Sieved done by NewPGen.

2003-07-13, 12:53	#8
TTn 546₁₀ Posts	I have informed Jean of the problem. Thomas did seem to say that PRP had the same behavior. Please try these k & n, with the old PRP and LLR. 504017085(n=104,117,126,133,605,649...?) 509070705(n=79,86,107,112,117,586...?) 515179665(n=76,80,85,110,118,123,126...?) These test are supposed to be deterministic! When a probable program gets better results, it is rather dissheartening. Bad news, I have doublechecked thirty k, with small values n<5000 All with these false negatives, which seem to appear on any line, and are gapped sporatically. No easily noticable pattern other than a sharp drop. Good news, I have doublechecked three k, with large values n<30000 and found no false negatives. Although I am still not satisfyed, that the falsees are more sparce with large n. Because they could decide to cluster in the area we just happen to be testing.

2003-07-13, 19:12	#10
dswanson Aug 2002 2³×5² Posts	I think TTn's logic for thinking it's the CPU is that the problem occurs on P4's, but not on AMDs or older Pentium series.

2003-07-13, 19:36	#11
ebx Aug 2002 101 Posts	You need to read the problem and problem description more carefully. The title of this thread is 'P4 SSE2 routine bug?'. That does sound like a software problem to me although it is not impossible that there are underlaying hardware bugs. Memory allocation is an issue of itself. It occurred but didnt contribute to the SSE2 bug reported. Maybe it was one of my posts that lead to the think of a hardware bug.