Comparison of changing --sieve-primes over increasing shift 48 - 256

In a post to the bitcointalk thread, j0nn9 describes the GapMiner parameters: “shift should be the most sensitive parameter, because it controls the bit size of the primes, second would be sieve primes”. The tests reported here are of systematic changes to the value of sieve-primes in non-CRT mining.

Each row of three tests is a single, simultaneous run and can be compared laterally - but not vertically because for each run of three tests, the difficulty changes and thwarts comparison. Of note is the std value, the standard deviation

Unlike mining at shift 25, it seems that at shift 48, increasing the number of primes in the sieve above the default 900000 starts to make a small positive difference, if one can see past the noise. So, it’s worth bumping up the sieve-primes value for non-CRT mining at higher shifts.

The final three tests check for any ceiling effect in sieve-primes settings that might be affecting the results, pushing the boundaries out to 20000000, in the interests of completeness and it appears that for the upper range of shifts with non-CRT mining, around 8000000 is optimal.

The charts included below are for completeness. The figures given are the means and they differ from the means in the above table because, in order to support the different requirements of charting, the first 1/5th of the data is ignored in order to aid visual comparison. The chartline uses the full dataset.

Replication:

gapminer -o localhost -p 31397 -u $USER -x $USERPASS -j 5 -e -t 3 -f 25 -s 33554397 -i 600000
gapminer -o localhost -p 31397 -u $USER -x $USERPASS -j 5 -e -t 3 -f 25 -s 33554397 -i 000000
gapminer -o localhost -p 31397 -u $USER -x $USERPASS -j 5 -e -t 3 -f 25 -s 33554397 -i 1200000