Multithreading existing code

[henryzz]

Originally Posted by robert44444uk

No one k was taken up as far as n=1e6, about 850k from memory was the highest. That k has more than 200 primes, and is the only known k with >200 primes.

Checking is quite slow for these k, because there is no really superfast sieve (although one could be constructed!), newpgen is not really geared from today's computers.

Also, because there are no small factors for any of the k*2^n+ or -1, a significantly greater number of n need a prp test. Hence a payam k series will remain, on average, more prime at any level of n compared to a random k because of this.

Unless I am mistaken it shouldn't be hard to modify mtsieve to efficiently sieve with large highly composite ks. Then you just have to deal with the generic multiply slowdown from gwnum.

[rogue]

Originally Posted by henryzz

Unless I am mistaken it shouldn't be hard to modify mtsieve to efficiently sieve with large highly composite ks. Then you just have to deal with the generic multiply slowdown from gwnum.

I would have suggested that, but I don't know how this other program works. Note that mtsieve will send a unique set of primes to each Worker, it is not designed to send the same set of primes to multiple Workers.

[henryzz]

Originally Posted by rogue

I would have suggested that, but I don't know how this other program works. Note that mtsieve will send a unique set of primes to each Worker, it is not designed to send the same set of primes to multiple Workers.

I was more thinking for the testing phase once you have the good candidates. extending srsieve2 to support ks > 64 bits shouldn't be that hard.