Software/instructions/questions

[rogue]

Originally Posted by Puzzle-Peter

What's the latest version of srsieve? I could find source code for 1.0.7 but the latest executable I found is 0.6.17. Is there a more recent executable for 64 bit linux somewhere?

Possibly. Are you able to build your own for Linux?

[Puzzle-Peter]

Originally Posted by rogue

Possibly. Are you able to build your own for Linux?

When it's not too complicated. I have gcc44 available.

[VBCurtis]

What's the flag to put into llr.ini to tell llr to ignore a k-value after a prime is found? It's not in the first post of this thread (that post still instructs us to use pfgw always, which is not fast, right?), and I'm too lazy to read the entire thread to find the fix.

Something like stoponprimedk=1?

[pepi37]

Originally Posted by VBCurtis

What's the flag to put into llr.ini to tell llr to ignore a k-value after a prime is found? It's not in the first post of this thread (that post still instructs us to use pfgw always, which is not fast, right?), and I'm too lazy to read the entire thread to find the fix.

Something like stoponprimedk=1?

StopOnPrimedK=1

[LaurV]

I am sieving 2*1909^n-1 100k<n<=200k, with both sr1sieve and sr2sieve starting from a pre-sieved file (done with srsieve to 1e9 or so) and I am getting different lists of factors. Am I doing something stupid, or I just uncovered a bug in sr1sieve that seems to miss many factors? Can anybody reproduce this?

(edit: you only need to sieve one minutes or so, the first difference appears at 1568702129 | 2*1909^169938-1, for which sr2sieve agrees, but sr1sieve disagrees)

[MisterBitcoin]

Originally Posted by LaurV

I am sieving 2*1909^n-1 100k<n<=200k, with both sr1sieve and sr2sieve starting from a pre-sieved file (done with srsieve to 1e9 or so) and I am getting different lists of factors. Am I doing something stupid, or I just uncovered a bug in sr1sieve that seems to miss many factors? Can anybody reproduce this?

(edit: you only need to sieve one minutes or so, the first difference appears at 1568702129 | 2*1909^169938-1, for which sr2sieve agrees, but sr1sieve disagrees)

sr1sieve gave me the following factor for your candidate.

1031811247 | 2*1909^169938-1

sr2sieve gave me the same result.

Booth factor files have the same factor count and found the same factors. (Tested from 1e9 up to 5e9)

Which versions from sr1sieve/sr2sieve are you using, can you upload your factor files?

[rogue]

The latest versions, sr1sieve 1.4.5 and sr2sieve 1.9.3 agree on factors on Win64. I have not made any code codes in either in over four years. If you are using those releases, but on a different OS, please let me know.

[LaurV]

Originally Posted by rogue

The latest versions, sr1sieve 1.4.5 and sr2sieve 1.9.3 agree on factors on Win64. I have not made any code codes in either in over four years. If you are using those releases, but on a different OS, please let me know.

I am using last versions, as indicated. The problem is reproducible on win7 64 bits, with an i7-6950x. Starting from a file with less than 11500 candidates remaining, generated with srsieve, I run in two different folders:

sr2sieve -P 5e12 -R 1500 -w -i sr_1909.pfgw

respectively

sr1sieve -P 5e12 -i sr_1909.pfgw -o t17_b1909.prp -f factors.out

The result has over 100 different lines, like this:


I will have to go to job today and see if the problem is reproducible on those computers there, and late tonight back home I will try the other computers, last night it was too late already.

[pepi37]

Originally Posted by LaurV

I am using last versions, as indicated. The problem is reproducible on win7 64 bits, with an i7-6950x. Starting from a file with less than 11500 candidates remaining, generated with srsieve, I run in two different folders:

sr2sieve -P 5e12 -R 1500 -w -i sr_1909.pfgw

respectively

sr1sieve -P 5e12 -i sr_1909.pfgw -o t17_b1909.prp -f factors.out

The result has over 100 different lines, like this:
Attachment 16141

I will have to go to job today and see if the problem is reproducible on those computers there, and late tonight back home I will try the other computers, last night it was too late already.

I do same initial sieve as you but my starting file has more then 11500 candidates left (11596) that is first difference.
Second using Sr1sieve i sr2sieve on Win7 x64 give me same output, same number of factors and same value as for MRBitcoinn ( 1031811247 | 2*1909^169938-1)
Third:
I use your command lines, and again got same results. same number of factors .

[LaurV]

Originally Posted by pepi37

I do same initial sieve as you but my starting file has more then 11500 candidates left (11596) that is first difference.
Second using Sr1sieve i sr2sieve on Win7 x64 give me same output, same number of factors and same value as for MRBitcoinn ( 1031811247 | 2*1909^169938-1)
Third:
I use your command lines, and again got same results. same number of factors .

Typo, less than 11600 (we get 11596 too). In hurry in the morning, to go to job.
More details:
- it only happenes on 6950X and only when all 20 cores (HT) are sieving (there are 21 bases left and I was sieving all in the same time) with sr2sieve (so the issue is with sr2sieve, not with sr1sieve). The additional factors appear when I sieve 20 or 21 of those bases.
- all additional factors that appear in the factor file are redundant (sometimes more than once), i.e. there exist lower factors for those candidates (see the example of MisterB above). Looks like somehow sr2sieve is saving all duplicates even if the candidate was eliminated.
- it is not related to temperature, the CPU is not stressed and it does not get hot (I can even run few more threads of cllr in the background with no speed/heat difference, but the problem will not occur with, say, 18 threads of sr2sieve and few threads of cllr)
- it is not related to the base, other bases behave exactly the same, see attached picture.



The reason I was using sr2sieve (instead of sr1sieve, as it woul be normal for a single base single k) is the -R switch which I don't have for sr1sieve. Otherwise I won't be stupid to plan willingly to run manual factor elimination, and I wouldn't use sr2sieve. The speeds of them both are identical. Why did I tried a double-check with sr1sieve for this base? (we talk about 1909). Well, long story short, after sieving to 5e12, all the other bases (2*b^n-1) have like 4k candidates left for 100k<n<200k, except this one which has 9k candidates left for cllr. I thought, what the hack, it may be a mistake, maybe I missed a zero or so, or it must be because there are 20 threads and 21 bases and maybe this one was left apart? Therefore I did it again only for this base, with sr1sieve. Well the result was the same, except for the ~100 less factors. But after eliminating the factors in both cases, I get the same final file for cllr in both cases, proving tht all were duplicates. It looks like this base has indeed much less amount of low factors than the other 20 bases.

But is still strange why sr2sieve behave in that way.

[LaurV]

Because we anyhow totally hijacked this thread...
(I elliminated the macros and DDE part, you can click on the plus signs or on the little 1/2 tabs on the upper left, or see the second sheet too)