[XPM] [ANN] Primecoin High Performance | HP14 released!

[primer-]

mikaelh
Have any plans to build standalone miner for Solo(getwork or getblocktemplate)? Xolo promise make it, but... only promise...

I'm not sure if I'm going to have the time to develop a standalone miner. Right now I have no plans for it. Hopefully someone will step up and make one.

Anyway thank you for your work.

Hi,
Regarding to  standalone miner check out my Github repository at https://github.com/hg5fm/jhPrimeminer
This one originally was written for ypool.org but now supports both getwork and getblocktemplate for solo mining.
Rdebourbon's 4.0F2 from https://mega.co.nz/#F!SMdjBZjA!ft7TBVIedEg820_3GFzEAQ is a more optimized version especially for solo mining supports getblocktemplate.
For linux  there is Tandyuk's  port from https://github.com/tandyuk/jhPrimeminer/tree/mumu-v8 . This one only works with getwork protocol so  the latest (original, non HP) primecoind is required to work with it.

I think i got the Rdebourbon's 4.0F2  working on Windows, where can i get the source to compile on linux ?

These are my stats solomining :
══════════════════════════════════════════════════════════════════════════════
12/25/13-14:21:41 - New Block: 329378 - Diff: 10.171724 / 10.171724
Best/Max diff: [ 0.000000 / 0.000000 ]
 6ch/h:     0.00 - 0 [ 0 / 0 / 0 ]
MNPS:670.52   PPS:13348        WPS:42.246   ACC:315
Current Primorial: 43 - Sieve Size: 1024000 - Prime Count: 25000
New Primes Count: 27500
══════════════════════════════════════════════════════════════════════════════

and HP11 :
[root@CentOS-64-64-minimal ~]# primecoind getmininginfo
{
    "blocks" : 329379,
    "chainspermin" : 4,
    "chainsperday" : 0.07622015,
    "currentblocksize" : 13776,
    "currentblocktx" : 15,
    "difficulty" : 10.17098707,
    "errors" : "",
    "generate" : true,
    "genproclimit" : -1,
    "primespersec" : 2411,
    "pooledtx" : 15,
    "sieveextensions" : 9,
    "sievepercentage" : 10,
    "sievesize" : 1000000,
    "testnet" : false
}


Which miner is doing better ?

[mhps]

mikaelh
Have any plans to build standalone miner for Solo(getwork or getblocktemplate)? Xolo promise make it, but... only promise...

I'm not sure if I'm going to have the time to develop a standalone miner. Right now I have no plans for it. Hopefully someone will step up and make one.

The reason that I don't do solo mining is because I don't know if the miner are working properly easily. So far from the display only finding a block does the miner display something. It can take days (now weeks) before I realize something is wrong. To check I have to run a script checking the 5ch/hour number hasn't changed to soemthing funny. I assume the 5-ch/hour number in the debug.log is a robust indicator of 10-ch/hr, which I am not sure about.
Is it possible to make an option so that if the miner finds a 8ch, which is more often, print out a line in the console or command line?

[mumus]

I think i got the Rdebourbon's 4.0F2  working on Windows, where can i get the source to compile on linux ?

These are my stats solomining :
══════════════════════════════════════════════════════════════════════════════
12/25/13-14:21:41 - New Block: 329378 - Diff: 10.171724 / 10.171724
Best/Max diff: [ 0.000000 / 0.000000 ]
 6ch/h:     0.00 - 0 [ 0 / 0 / 0 ]
MNPS:670.52   PPS:13348        WPS:42.246   ACC:315
Current Primorial: 43 - Sieve Size: 1024000 - Prime Count: 25000
New Primes Count: 27500
══════════════════════════════════════════════════════════════════════════════

and HP11 :
[root@CentOS-64-64-minimal ~]# primecoind getmininginfo
{
    "blocks" : 329379,
    "chainspermin" : 4,
    "chainsperday" : 0.07622015,
    "currentblocksize" : 13776,
    "currentblocktx" : 15,
    "difficulty" : 10.17098707,
    "errors" : "",
    "generate" : true,
    "genproclimit" : -1,
    "primespersec" : 2411,
    "pooledtx" : 15,
    "sieveextensions" : 9,
    "sievepercentage" : 10,
    "sievesize" : 1000000,
    "testnet" : false
}


Which miner is doing better ?

Rdebourbon didn't released his code, so it's only for windows. You may run with wine under Linux. There is no good way to compare the 2 miners except running on a big server farm for a couple of days and see the outcome. In our miner an acceptable way to estimate the number of 10ch/day is to calculate it form 8ch/h and 9ch/h. The factor used to be 10x but I'm not sure it's still true with 10ch.  I'm also using Rde4.0f2 and my own build in solo mode on 3-4 computers and  time to time I get a block.

[mikaelh]

Here's my fix for the issue with shared wallets I discovered earlier:
https://github.com/mikaelh2/primecoin/commit/a1c3f5854e9970d2f9f13ff75601dc7c87bf83c3

Basically this should help people who are running lots of miners using the same shared wallet. My fix is to initialize the extra nonce value using the current value of a nanosecond-precision clock. That should give a unique value on every machine. Boost.Chrono is now required for compiling and I have updated the makefiles to reflect that.

[ivanlabrie]

Here's my fix for the issue with shared wallets I discovered earlier:
https://github.com/mikaelh2/primecoin/commit/a1c3f5854e9970d2f9f13ff75601dc7c87bf83c3

Basically this should help people who are running lots of miners using the same shared wallet. My fix is to initialize the extra nonce value using the current value of a nanosecond-precision clock. That should give a unique value on every machine. Boost.Chrono is now required for compiling and I have updated the makefiles to reflect that.

Thanks a lot!

[primer-]

Here's my fix for the issue with shared wallets I discovered earlier:
https://github.com/mikaelh2/primecoin/commit/a1c3f5854e9970d2f9f13ff75601dc7c87bf83c3

Basically this should help people who are running lots of miners using the same shared wallet. My fix is to initialize the extra nonce value using the current value of a nanosecond-precision clock. That should give a unique value on every machine. Boost.Chrono is now required for compiling and I have updated the makefiles to reflect that.

Thanks!! Someone please compile x86 and x64 builds.

Edit: unable to compile on centos 6.4 x64 :
ain.cpp: In function ‘void BitcoinMiner(CWallet*)’:
main.cpp:4578: error: ‘boost::chrono’ has not been declared
main.cpp:4578: error: expected ‘;’ before ‘time_now’
main.cpp:4579: error: ‘boost::chrono’ has not been declared

boost_1_55_0 compiled successfully.

[mikaelh]

Here's my fix for the issue with shared wallets I discovered earlier:
https://github.com/mikaelh2/primecoin/commit/a1c3f5854e9970d2f9f13ff75601dc7c87bf83c3

Basically this should help people who are running lots of miners using the same shared wallet. My fix is to initialize the extra nonce value using the current value of a nanosecond-precision clock. That should give a unique value on every machine. Boost.Chrono is now required for compiling and I have updated the makefiles to reflect that.

Thanks!! Someone please compile x86 and x64 builds.

Edit: unable to compile on centos 6.4 x64 :
ain.cpp: In function ‘void BitcoinMiner(CWallet*)’:
main.cpp:4578: error: ‘boost::chrono’ has not been declared
main.cpp:4578: error: expected ‘;’ before ‘time_now’
main.cpp:4579: error: ‘boost::chrono’ has not been declared

boost_1_55_0 compiled successfully.

You can get it to compile on CentOS but it's a bit more tricky than before. You need to have a newer version of boost installed. Then you need to tell the compiler where you installed the newer boost. By default it goes into /usr/local. Then you need to modify the makefile like this:

Code:

cp makefile.unix makefile.my
sed -i -e 's/$(OPENSSL_INCLUDE_PATH))/$(OPENSSL_INCLUDE_PATH) \/usr\/local\/include)/' makefile.my
sed -i -e 's/$(OPENSSL_LIB_PATH))/$(OPENSSL_LIB_PATH) \/usr\/local\/lib)/' makefile.my
sed -i -e 's/$(LDHARDENING) $(LDFLAGS)/$(LDHARDENING) -Wl,-rpath,\/usr\/local\/lib $(LDFLAGS)/' makefile.my

And then you type 'make -f makefile.my' to compile.

Official binaries will be coming soon. I want to see if I can downgrade my glibc version first somehow. If I can get the glibc version down to 2.12, the binaries should work on CentOS.

[primer-]

Here's my fix for the issue with shared wallets I discovered earlier:
https://github.com/mikaelh2/primecoin/commit/a1c3f5854e9970d2f9f13ff75601dc7c87bf83c3

You can get it to compile on CentOS but it's a bit more tricky than before. You need to have a newer version of boost installed. Then you need to tell the compiler where you installed the newer boost. By default it goes into /usr/local. Then you need to modify the makefile like this:

Official binaries will be coming soon. I want to see if I can downgrade my glibc version first somehow. If I can get the glibc version down to 2.12, the binaries should work on CentOS.

Thanks, got it compiled on centos 6.4, both x86 and x64. Full boost1.5 installation was required

Code:

wget http://sourceforge.net/projects/boost/files/boost/1.55.0/boost_1_55_0.tar.gz/download
tar xfvz boost_1_55_0.tar.gz >/dev/null
cd boost*
./bootstrap.sh
./b2 install

This will take good 10 minutes to compile on a decent processor.
Once completed compile hp11 from github

Code:

git clone --recursive https://github.com/mikaelh2/primecoin/
cd primecoin/src
cp makefile.unix makefile.my
sed -i -e 's/$(OPENSSL_INCLUDE_PATH))/$(OPENSSL_INCLUDE_PATH) \/usr\/local\/include)/' makefile.my
sed -i -e 's/$(OPENSSL_LIB_PATH))/$(OPENSSL_LIB_PATH) \/usr\/local\/lib)/' makefile.my
sed -i -e 's/$(LDHARDENING) $(LDFLAGS)/$(LDHARDENING) -Wl,-rpath,\/usr\/local\/lib $(LDFLAGS)/' makefile.my
make -f makefile.my

Anyone got it compiled on Windows ?

[AnhBen]

This is Primecoin High Performance, a Primecoin wallet with high-performance miner built-in. Only solo mining is supported. For pooled mining, see beeeeer.org. The main Primecoin thread is here.

Features:
 * Extended sieve algorithm
 * Adjustable sieve parameters
 * Utilizes GMP for faster bignum arithmetic

Changelog:
Changes in -hp2:
 * Restored sieve size to 1,000,000. Quick runs on the testnet show significantly increased probable prime chain rate. Thanks to the numerous people who pointed this out.

Changes in -hp3:
 * Added a new tuning parameter "sievesize". Default value is 1M, minimum is 100k, maximum is 10M.
 * Some other minor performance improvements
 * Merged two pull requests from geeknik that eliminate references to "Bitcoin"

Changes in -hp4:
 * Added more L1 and L2 cache optimizations
 * Some other minor performance improvements (including a change originally by luke-jr)
 * New experimental performance metric 5-chains/h in debug.log

Changes in -hp5:
 * Added a faster 32-bit routine for inverting numbers
 * Other minor performance improvements to the sieve

Changes in -hp6:
 * Added fast divisibility tests before doing the expensive Fermat's test
 * Lots of other small optimizations
 * Introduced a new experimental tuning parameter "sievepercentage". Default value is 10, minimum is 1, maximum is 100.
 * Added new RPC command "getchainspermin"
 * Added the following information to "getmininginfo": chainspermin, difficulty, sievepercentage, and sievesize
 * Attempt to fix the random crash while mining

Changes in -hp7:
 * IMPORTANT: Sunny King's fix for mining large block sizes
 * Small performance improvement to the sieve

Changes in -hp8:
 * IMPORTANT: Fixed loss of potential blocks caused by fractional length calculation being skipped if fast divisibility test succeeds. (Thanks to mtrlt for spotting this.)
 * Skip fractional length calculation for the first number in a chain (as suggested by gatra).
 * Added a new configurable round primorial adjustment system.
 * Round primorial can be adjusted through the -roundsievepercentage parameter (default value is 30, minimum is 1, maximum is 100). The parameter depends how much time is spent running the sieve. By default 30% of time is spent in the sieve and 70% is spent on checking the candidates produced by the sieve.
 * Lots of other performance improvements.
 * Bigger sieve sizes should no longer crash on Windows.
 * Added new RPC commands setsievepercentage and setroundsievepercentage for changing parameters on the fly.
 * GMP is now included as a separate library in the binary releases.

Changes in -hp9:
 * Sunny's mining optimizations from 0.1.2.
 * Minor mining optimizations from mtrlt and gatra.
 * Small sieve optimizations for 32-bit processors.
 * Sunny's new chains/day estimate.
 * Sunny's new 'listprimerecords' RPC command.
 * New default value for roundsievepercentage is 70 on mainnet (better chains/day, equal 5-chains/h).

Changes in -hp10: (ann)
 * Major rewrite of the sieve to support extending the sieve (originally implemented by jh000).
 * Added a new parameter 'sieveextensions' which controls how many times the sieve is extended.
 * Removed the problematic and unnecessary fast-division test.
 * Changed the value of nL1CacheElements to 224000 which is slightly faster (thanks to nushor on IRC).
 * The 'roundsievepercentage' parameter is gone. The round primorial is now automatically adjusted.
 * New RPC command 'listtopprimes' by Sunny.

Changes in -hp11: (ann)
 * Fixed a bug in the BiTwin filter that was inflating the chains/day estimate and reducing the chances of finding a block (thanks to rdebourbon).
 * Slightly improved the accuracy of the prime probability estimate with regards to the 'sieveextensions' parameter.
 * Changed the default value of 'sieveextensions' to 9.
 * Other small fixes and improvements from cabin.

Windows x64 binaries
http://sourceforge.net/projects/primecoin-hp/files/0.1.2-hp11/primecoin-0.1.2-hp11-winx64.zip/download
https://mega.co.nz/#!F511ERZD!LmHvfyjFayOIG7cgoRdcogd10GogsoKj4Lz0TPCyt8Q
SHA1SUM: 319d93b07ab71a6ec049bbe9fac10f97120ac2ef

Windows x86 binaries
http://sourceforge.net/projects/primecoin-hp/files/0.1.2-hp11/primecoin-0.1.2-hp11-winx86.zip/download
https://mega.co.nz/#!F4ETFBrB!cHVgBT4r-bJOgAWZf8TorUyPnQpTt9HRNYTMGkIwfSI
SHA1SUM: 9056ef50bb33af1639e2b0c271073639cbc825d8

Linux x64 and x86 binaries
http://sourceforge.net/projects/primecoin-hp/files/0.1.2-hp11/primecoin-0.1.2-hp11-linux.tar.bz2/download
https://mega.co.nz/#!I0MHUAZC!bflKLko0qnO7nM2ZTV9V6lfX_HoxrSpLtBykd2wmykI
SHA1SUM: 7cdf4870fc532a5357f8588ac66ab191f0592b78

Warning to Linux users: My binaries are linked against Berkeley DB 4.8.30. If you have compiled from source before, the database format may be incompatible if you linked against a different version of Berkeley DB. Sunny King's original binaries are linked against Berkeley DB 4.8.24 and should be compatible with my version. Always make sure to backup the database and your wallet before switching builds.

Source code (.tar.bz2)
http://sourceforge.net/projects/primecoin-hp/files/0.1.2-hp11/primecoin-0.1.2-hp11.tar.bz2/download
https://mega.co.nz/#!l4EkiZbI!GSnmJEyL0N4JktHlKnY0Nzl6JL4YP8UzYvRabgM1Axg
SHA1SUM: 3fec6fc6fc4c3673b462df8fcced927ce92590d8

Source code (Git)
https://bitbucket.org/mikaelh/primecoin-hp
https://github.com/mikaelh2/primecoin

Please use the SourceForge link for downloading the source code to ease the load on the repository.

New compilation guide for Linux is here:
https://bitcointalk.org/index.php?topic=259022.0

Older releases are stored on SourceForge:
https://sourceforge.net/projects/primecoin-hp/files/

This release includes mustyoshi's patch from this post:
https://bitcointalk.org/index.php?topic=251850.msg2689981#msg2689981

Configuration

Sample config file for automatic mining:

Code:

gen=1
seednode=primeseed.muuttuja.org

Tuning options:
sievesize (default value: 1M)
sievepercentage (default value: 10)
sieveextensions (default value: 9)

FAQ

Q: How many blocks should I expect to find?
A: My current formula for turning chains/day into blocks/day is as follows:
blocks/day = chains/day * (1 - fracDiff + 0.035)
Here fracDiff is the fractional part of the mining difficulty. The 'getmininginfo' will show both the chains/day value and the difficulty.

Q: Is this compatible with the original client? Can I replace primecoin-qt/primecoind with this release?
A: Yes, the Windows builds should be compatible with the original client. It uses Berkeley DB version 4.8 so the database format should be the same.

Q: Why is the client crashing with the following message?
Assertion failed!
File: src/checkqueue.h, line 171
Expression: pqueue->nTotal == pqueue-> nIdle
A: This is a known bug which is present both in this version and the original Primecoin wallet. A workaround is to use a script or a cron job to automatically restart the wallet.

Q: How can I fix the client crashing on every startup?
A: Try deleting all database files except wallet.dat.

Q: Where is the config file located?
A: Windows users: The configuration file should be located in the %APPDATA%\Primecoin folder.
Linux users: Configuration file is located inside the ~/.primecoin directory.
The configuration file is not created by default. If it does not exist, simply create a new text file and save it as primecoin.conf.

Q: What are the optimal sieve parameters?
A: The default values should be good for most people. If you want to further optimize them, adjust them one-by-one and compare chains/day.

Q: Why is my performance worse on Linux?
A: This version relies on libgmp to do most of the complex calculations. Make sure your libgmp is up-to-date. Old versions do not support newer CPUs. I suggest compiling your own libgmp from latest source code for maximum performance.

Q: Why has my prime rate dropped after updating?
A: There are two common cases why primes/s can drop:
1. You downloaded the 32-bit version which is slower. Use the 64-bit version if possible.
2. Network difficulty has changed. Prime rate goes down when the integer part of the difficulty changes (i.e. going from 8.xx to 9.xx). It's a feature of the mining algorithm and nothing can be done about it.
Otherwise please make a post wiith system information (especially CPU model), operating system version and miner version.

Q: What is the chains/day estimate?
A: Short version: https://bitcointalk.org/index.php?topic=255782.msg2847844#msg2847844
Longer version: https://bitcointalk.org/index.php?topic=255782.msg2848092#msg2848092

Q: How do I solve a problem with the client not being able to synchronize or connect to any nodes?
A: Try adding this line to your primecoin.conf file:

Code:

seednode=primeseed.muuttuja.org

Also check that your firewall allows outgoing connections to other nodes. You may also allow incoming connections if you want. The default port used by Primecoin is 9911 (TCP).

What are the best settings to get the most out of this HP?

[ReCat]

Magic.

[mhps]

What are the best settings to get the most out of this HP?

Try not quoting a full page and asking a one liner.

[Trillium]

What are the best settings to get the most out of this HP?

I think I've said it 1000 times now.

If you just discovered primecoin/hp and you have to ask this question, then the answer is "just leave it alone and run the default settings".

[AnhBen]

What are the best settings to get the most out of this HP?

I think I've said it 1000 times now.

If you just discovered primecoin/hp and you have to ask this question, then the answer is "just leave it alone and run the default settings".

I have more than 100 instances of VPS!

[OnkelPaul]

I have more than 100 instances of VPS!

Then you should probably experiment with settings if you believe that the default settings might not be optimal.
For example, you might adjust one setting for half of these instances and run the whole lot for some days to see whether it makes a difference.
If the new setting is better than the old one, use it for the other half and either adjust another setting, or adjust the same setting a little more in the same direction.
Sort of running a genetic optimization algorithm manually.

If you don't want to go through the hassle, you should probably just take the default settings. They are default because the authors thought that they yield best results in normal cases.

Onkel Paul

[SStalin]

I do not understand with  10 up to 11 in how many times there will be a difference in processor capacities?

[Trillium]

Sort of running a genetic optimization algorithm manually.

Said as if the typical person does them daily.

[OnkelPaul]

Sort of running a genetic optimization algorithm manually.

Said as if the typical person does them daily.

Well nature does it all the time, it can't be that hard :-)
... Actually, if you don't have a sound mathematical model of how the parameters affect mining performance, it's about the only thing you can do: experiment and adjust.
Of course, just keeping the default parameters which should be well-tested already is a lot easier.

Onkel Paul

[AnhBen]

I have more than 100 instances of VPS!

Then you should probably experiment with settings if you believe that the default settings might not be optimal.
For example, you might adjust one setting for half of these instances and run the whole lot for some days to see whether it makes a difference.
If the new setting is better than the old one, use it for the other half and either adjust another setting, or adjust the same setting a little more in the same direction.
Sort of running a genetic optimization algorithm manually.

If you don't want to go through the hassle, you should probably just take the default settings. They are default because the authors thought that they yield best results in normal cases.

Onkel Paul

Do you know what PPS is the best to get lucky because I could ramp up the cores to get better results? Like if the PPS is more than 1k then I can have all of my instances average above that number instead of having less with higher PPS. Is this the best strategy?

[Supercomputing]

I have more than 100 instances of VPS!

Then you should probably experiment with settings if you believe that the default settings might not be optimal.
For example, you might adjust one setting for half of these instances and run the whole lot for some days to see whether it makes a difference.
If the new setting is better than the old one, use it for the other half and either adjust another setting, or adjust the same setting a little more in the same direction.
Sort of running a genetic optimization algorithm manually.

If you don't want to go through the hassle, you should probably just take the default settings. They are default because the authors thought that they yield best results in normal cases.

Onkel Paul

Do you know what PPS is the best to get lucky because I could ramp up the cores to get better results? Like if the PPS is more than 1k then I can have all of my instances average above that number instead of having less with higher PPS. Is this the best strategy?

Searching for Cunninghan chains (Primecoin/Datacoin mining) involves the following steps:
[Double SHA-256 for the block/block header hashing (CPUs are dreadfully slow for this task)
Modular reduction per sieving prime (using the double SHA-256 result from the block header hash)
Modular multiplicative inverse per sieving prime (using the result from the previous step - we need a starting point for the sieving prime)
Bit array masking or call it sieving (using an array of 32-bit integers that should fit in your CPU's L1 data cache: AMD 64KB, Intel 32KB)
Modular exponentiation on the CPU - sliding window (GMP: Karatsuba + Montgomery reduction)

Now remember that we are searching for chains and not for primes, therefore Primes Per Second (PPS) means absolutely nothing by itself. Your goal is to actually reduce the number of PPS while increasing your number of  probable chains per second (CPS). During your sieving/bit masking process, what you are actually doing is eliminating all of the composite numbers/false chains that would never meet the requirements for your current difficulty. Therefore, the theoretical ratio for difficulty 10 is: 10PPS / 1CPS

So where does tuning come in? First find out if you are running on AMD processors (K10), if so, then double the cache settings and recompile. You may also have to lower your sieve extensions because the AMD processors typically have 64KB/64KB for L1 instruction/data caches. If you are running on Intel processors then Mikaelh's code should work well as is. Tuning involves finding the cutoff point where sieving is no longer as effective as performing modular exponentiation to eliminate false chains per unit of time.

[AnhBen]

I have more than 100 instances of VPS!

Then you should probably experiment with settings if you believe that the default settings might not be optimal.
For example, you might adjust one setting for half of these instances and run the whole lot for some days to see whether it makes a difference.
If the new setting is better than the old one, use it for the other half and either adjust another setting, or adjust the same setting a little more in the same direction.
Sort of running a genetic optimization algorithm manually.

If you don't want to go through the hassle, you should probably just take the default settings. They are default because the authors thought that they yield best results in normal cases.

Onkel Paul

Do you know what PPS is the best to get lucky because I could ramp up the cores to get better results? Like if the PPS is more than 1k then I can have all of my instances average above that number instead of having less with higher PPS. Is this the best strategy?

Searching for Cunninghan chains (Primecoin/Datacoin mining) involves the following steps:
[Double SHA-256 for the block/block header hashing (CPUs are dreadfully slow for this task)
Modular reduction per sieving prime (using the double SHA-256 result from the block header hash)
Modular multiplicative inverse per sieving prime (using the result from the previous step - we need a starting point for the sieving prime)
Bit array masking or call it sieving (using an array of 32-bit integers that should fit in your CPU's L1 data cache: AMD 64KB, Intel 32KB)
Modular exponentiation on the CPU - sliding window (GMP: Karatsuba + Montgomery reduction)

Now remember that we are searching for chains and not for primes, therefore Primes Per Second (PPS) means absolutely nothing by itself. Your goal is to actually reduce the number of PPS while increasing your number of  probable chains per second (CPS). During your sieving/bit masking process, what you are actually doing is eliminating all of the composite numbers/false chains that would never meet the requirements for your current difficulty. Therefore, the theoretical ratio for difficulty 10 is: 10PPS / 1CPS

So where does tuning come in? First find out if you are running on AMD processors (K10), if so, then double the cache settings and recompile. You may also have to lower your sieve extensions because the AMD processors typically have 64KB/64KB for L1 instruction/data caches. If you are running on Intel processors then Mikaelh's code should work well as is. Tuning involves finding the cutoff point where sieving is no longer as effective as performing modular exponentiation to eliminate false chains per unit of time.

Thx, that's very helpful! Is there any kind of documentations on tuning it to maximize the ROI?