Wilson-prime search practicalities

[pinhodecarlos]

Please let's coordinate a search effort. I would like to join to help out with preference under win 64. If not possible I would need some direction on how to start and run the client under linux. If a build with 4 instances can be shared in a zipped file, where I would only need to unpack and run it, would be great.

[Jeff Gilchrist]

Originally Posted by R. Gerbicz

As far as I know currently there is no running code at David and Edgar or at other team.

What parameters were you using around the 2e13 limit that you reached?

[R. Gerbicz]

Originally Posted by Jeff Gilchrist

What parameters were you using around the 2e13 limit that you reached?

We had to use all but two e values, the only exceptions were e=84 and e=90. The code selects those primes from the [st,en] interval for that the given 'e' is the best, with this we test each prime at exactly once (and not multiple times).
This is the easy part, and the code do everything, if needed then update the start point etc. as you have seen.

The hard part was to guess the memory usage for different type of clusters, some of them had peak in the 2nd stage (the goal was the 1st stage). But it was possible to find 'const' value for that it was at most const*interval*log(en). We used all memory on each cluster. And all cores, but it isn't needed for the code, and it is also possible to use different number of cores after a restart (that's the reason why I don't save the number of used cores).

We have seen at some clusters that there was a memory jump after a completed 'interval' of primes (examined this, but still don't know why it happens). So on each run we had to test only 1 block of interval to avoid this, so in [st,en] there were at most interval primes for given 'e'.

[Jeff Gilchrist]

Originally Posted by R. Gerbicz

We had to use all but two e values, the only exceptions were e=84 and e=90. The code selects those primes from the [st,en] interval for that the given 'e' is the best, with this we test each prime at exactly once (and not multiple times).
This is the easy part, and the code do everything, if needed then update the start point etc. as you have seen.

Just to clarify, you need to use each e value for every range, or you mean you ended up having to use all e value throughout your search to change the amount of memory being used depending on the system?

[R. Gerbicz]

Originally Posted by Jeff Gilchrist

Just to clarify, you need to use each e value for every range, or you mean you ended up having to use all e value throughout your search to change the amount of memory being used depending on the system?

The peak memory doesn't depend on the 'e' value, but on the running time it has a great effect, larger e gives faster 1st stage, but in general slower 3rd stage (it has got some effect on the 2nd stage also). The treshold table comes from an optimization that minimizes the overall runtime assuming that we can run all cores with all memory. This table given us that we have to use 28 'e' values up to 2e13, and yes we have to use all 'e' values up to this bound, but only from their treshold, say use e=8 from 815074496056LL.

And every kind of 'e' value has run on the slower machines. Obviously we could use only the fastest computers with 256GB Ram to minmize the cpu clock time but it would require much more wall clock time.

[henryzz]

I am assuming that you go through the huge amount of peak memory pretty quickly. Otherwise I might be possible to write some of it to disk(especially on a ssd).

[rogue]

Originally Posted by R. Gerbicz

I plan to write a similar code to search Wolstenholme primes, we won't do it with David and Edgar, so we could search them here.
Need some months to complete the code. It will be also a parallel code, using also the ntt library for parallel multiplication.

Did this ever happen?