Comparison of changing --sieve-size (ineffective at shifts < 768 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” and makes no mention of the --sieve-size parameter, implying that it has little influence on miner performance (it plays no role at all in CRT mining.

Confirming that changing --sieve-size has no statistically-significant (less than the standard deviation values in the tabular data shown below) effect at shift 64 or 128 (nor at any shift up to 512, although those results are not reported here).

At shift 768 however, some improvement was detected when the value was reduced from the default (with --sieve-primes also adjusted away from the default).

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 -f  64 -s 13554397 -i [as-discovered] -t 3
gapminer -o localhost -p 31397 -u $USER -x $USERPASS -j 5 -e -f  64 -s 33554397 -i [as-discovered] -t 3
gapminer -o localhost -p 31397 -u $USER -x $USERPASS -j 5 -e -f  64 -s 53554397 -i [as-discovered] -t 3
gapminer -o localhost -p 31397 -u $USER -x $USERPASS -j 5 -e -f 128 -s 13554397 -i [as-discovered] -t 4
gapminer -o localhost -p 31397 -u $USER -x $USERPASS -j 5 -e -f 128 -s 33554397 -i [as-discovered] -t 3
gapminer -o localhost -p 31397 -u $USER -x $USERPASS -j 5 -e -f 128 -s 53554397 -i [as-discovered] -t 3