Is there a need for an automated sieving system?

Simply put, a way for a server to maintain a db with clients connecting and getting sieve ranges to work on then returning factors?

It doesn't seem to me that such a thing exists, but that such a thing might provide value.

I could see it being useful for people that try their own searches in private, but otherwise I think PrimeGrid should just put everything onto BOINC.
____________

There will probably always be a case for manual sieving in the early stages, where the sheer number of factors removed is massive!
____________

In " Is it technically possible to move factorial and primorial searches to BOINC?" thread, there were two particular questions.

Question #1, how would pfgw need to change to support BOINC?

Question #2, how far has the sieving gone? mfsieve (part of the mtsieve framework), which replaced fpsieve/fsieve/fsievecl, can sieve up to 2^62.

Q1 was addresses, but not #2.

After some digging, both in my memory and on forums, I remember we were doing Primorial and Factorial sieves using manual sieving offline and uploading factor files and later combined them to make candidate list.
Primorial Prime Search Sieving
It was 10-15 years ago, CPU only, no MT.

I don't think I would be able to find original factor files to have better estimate how far was the sieving done.
Got an idea: if we sieve some sample ranges and compare then with candidates on PRPNet, would it give us good estimate?

Both PSieve and MTSieve have GPU versions.
Aren't those app's sieve limit much higher than we have acomplished 10-15 years ago?
This may be viable option...

Question for Mark of whoever is more familiar with MTSieve.

>psievecl.exe -n 4M -N 10M -p 7000G -P 7001G -g 64 -G 8 -W 4 -w 5000
>mfsievecl.exe -n 4M -N 10M -p 7000G -P 7001G -g 64 -G 8 -W 4 -w 5000

PSieve is much faster but gives less factors, comparing to MFSieve.
Any good explanation?
Missing factors or I'm missing something? Or both :-)
____________
My stats

I did some research on factorials recently.

Good:

We don't need PFGW anymore. Pavel wrote new own prime testing program which can do fast DC on factorials and primorials.

Everything else is bad:

Factorials were sieved up to N=1M only. Sieving depth was 10000G (sieving of factorials is very slow). May be it's optimal, may be not, main problem is not here. Need to analyze how much work we have. Considering PG crunching rates, it may happen that project will run out candidates in 2-3 months.

Sieving next range (up 2M) will take time twice as previous sieving. There is no fast algorithm for factorials. Sieving for N=2M means that on each iteration program will calculate factorials up to 2M. It also means that sieving program will, in fact, re-sieve everything up 1M again - even if these tests are not included in sieve file, all these iteration are executed anyway, just no factors reported.

Numbers near N=2M will be as big as current SoB. I.e. even if we'll sieve next range, it'll add only small amount of candidates of reasonable length. Most of new added candidates will be big and not fun to crunch.

I did some research on factorials recently.

For n between 1e6 and 2e6 you will likely need to sieve more deeply than 1e15.

I started n!6 earlier this year to 1e6 and I could sieve about 1e13 a month. The removal rate was well below what I would need if I were to test to the max n in the sieve. I stopped sieving at 5e13 and am PRP testing now. I guesstimated that I would need to sieve to about 5e14 to fully sieve the range. Since n! is much larger than n!6, I'm thinking that 2e16 will be closer to optimal sieving depth, but that is just a guess.

Or we may need to sieve deeper, not 10T but 100T or 1000T
1T - 10T, expecting 153846 factors
10T - 100T, expecting 142857 factors.
100T - 1000, expecting 133333 factors.

Am I reading it correctly that sieving up to 1000T will remove about 20% more candidates comparing to sieve up to 1T?

Sieving to 1e15 / 1000T would generate work for ~200 GPUs and a month running 24/7.
2e16 is job for 365 GPUs running 365 days.
This size would need BOINC platform and it's participants.
____________
My stats

I'm looking into a change for mfsieve/mfsievecl to speed up sieving. It won't double the speed for 1e6 < n < 2e6, but it should be more than 50% faster. It is a matter of computing 1e6! mod p faster than what it does today.