Comparison of changing --sieve-primes (essentially ineffective in non-CRT mining)

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 - it swamps any lateral differences, meaning that the changes had no statistically significant effect - apart from the last run in which the number of primes in the sieve was reduced to 5000 and that does seem have cramped GapMiner’s style somewhat. Increasing the value has no apparent effect for non-CRT mining.

The basic conclusion - for non-CRT mining (), the default of 900000 is just fine and doesn’t benefit from being increased. (I needed to check this for the purposes of designing the GUI for the client’s Mining tab). By contrast, the value set for sieve-primes is influential on performance when mining with CRT.

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