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

[maco]

Is there anyway to find out which version of the HP* I have installed?

Getinfo just shows which just shows the primecoin rev:

{
"version" : "v0.1.1.0-unk-beta",
"protocolversion" : 70001,
"walletversion" : 60000,
"balance" : 203.26000000,
"blocks" : 82636,
"moneysupply" : 1193468.71000000,
"timeoffset" : -1,
"connections" : 8,
"proxy" : "",
"testnet" : false,
"keypoololdest" : 1373284836,
"keypoolsize" : 106,
"paytxfee" : 0.00000000,
"errors" : ""
}

Good idea... That would come in handy

[1714112961]

1714112961

[1714112961]

1714112961

[hatto47]

I am currently testing the latest commits, it seems that the PPS indicator is very low compared to the value before, more than halved my numbers and chainspermin is 0 mostly all the time.
I will keep on testing, meanwhile, is anybody else testing the CURRENT version and seeing the same results out there ?

This happened for me too, on my Debian server with an i5-3570. I can't get even 1k PPS anymore, and chainspermin is around 1. HP7 was performing much better before. I don't have this performance problem with the newest version on an Ubuntu VirtualBox installation.

Here with Ubuntu 10.04 and i7-950 it's the same. PPS 300-700. Is use a self compilied GMP-lib.

[mumus]

Is there anyway to find out which version of the HP* I have installed?

Currently there isn't. You can try comparing your binary file against different releases.

Also I found the reason for the performance regression. The latest code seems to get stuck on using too low round primorials.

Hi,
I'm also trying to see what are the optimal parameters and based on my testing I found that nTestsAtOnce = 500 in the MineProbablePrimeChain() functions doesn't gives me the optimal performance.
I tested it with 5chain performance and I introduced for myself also 6chain average and tested mainly against this value. For me the optimal value was around nTestsAtOnce = 1800. I also used sievesize 800000, and sievepercentage over 50 gave better results. PPS is not at all a performance indicator here.

Edit: I made some other modifications as well that I can't remember now so if anybody want to test these values may not get the same results.

[mikaelh]

Also I found the reason for the performance regression. The latest code seems to get stuck on using too low round primorials.

The performance regression should be fixed by latest commit on bitbucket.

[mikaelh]

Is there anyway to find out which version of the HP* I have installed?

Currently there isn't. You can try comparing your binary file against different releases.

Also I found the reason for the performance regression. The latest code seems to get stuck on using too low round primorials.

Hi,
I'm also trying to see what are the optimal parameters and based on my testing I found that nTestsAtOnce = 500 in the MineProbablePrimeChain() functions doesn't gives me the optimal performance.
I tested it with 5chain performance and I introduced for myself also 6chain average and tested mainly against this value. For me the optimal value was around nTestsAtOnce = 1800. I also used sievesize 800000, and sievepercentage over 50 gave better results. PPS is not at all a performance indicator here.

Edit: I made some other modifications as well that I can't remember now so if anybody want to test these values may not get the same results.

Well, nTestsAtOnce should have only minimal impact on performance. It's there so that the call won't block the main loop for too long.

Sievesize and sievepercentage definitely do affect performance but you have to do your statistics properly with those. Preferably you should be measuring actual block rate.

Also if you happen to be testing on mainnet, make sure you grab my fix for the performance regression.

[n4ru]

Is there anyway to find out which version of the HP* I have installed?

Currently there isn't. You can try comparing your binary file against different releases.

Also I found the reason for the performance regression. The latest code seems to get stuck on using too low round primorials.

Why not just change the version string?

[mikaelh]

Is there anyway to find out which version of the HP* I have installed?

Currently there isn't. You can try comparing your binary file against different releases.

Also I found the reason for the performance regression. The latest code seems to get stuck on using too low round primorials.

Why not just change the version string?

I plan to.

[MayDee]

Will there be a hp8 release soon?

[mikaelh]

Will there be a hp8 release soon?

Probably yes. The current code is looking good now that the performance regression has been fixed.

[Dsfyu]

Will there be a hp8 release soon?

Probably yes. The current code is looking good now that the performance regression has been fixed.

Thanks for the update! I can't wait for the new hp8 release.

[juhakall]

Also I found the reason for the performance regression. The latest code seems to get stuck on using too low round primorials.

The performance regression should be fixed by latest commit on bitbucket.

I'm still getting poor performance with the latest commit, it doesn't look like the fix helped at all.

[mikaelh]

Also I found the reason for the performance regression. The latest code seems to get stuck on using too low round primorials.

The performance regression should be fixed by latest commit on bitbucket.

I'm still getting poor performance with the latest commit, it doesn't look like the fix helped at all.

Can you be more specific how your performance is poor? Are you looking at primes/sec, chain/min, block rate or something else? Also remember to not compare any numbers against previous network difficulties.

EDIT: It seems you may be right. Most of my own tests are still showing poor performance.
EDIT2: Large sieve sizes trigger pretty much the same performance bug.

[juhakall]

Also I found the reason for the performance regression. The latest code seems to get stuck on using too low round primorials.

The performance regression should be fixed by latest commit on bitbucket.

I'm still getting poor performance with the latest commit, it doesn't look like the fix helped at all.

Can you be more specific how your performance is poor? Are you looking at primes/sec, chain/min, block rate or something else? Also remember to not compare any numbers against previous network difficulties.

EDIT: It seems you may be right. Most of my own tests are still showing poor performance.
EDIT2: Large sieve sizes trigger pretty much the same performance bug.

I've been using sievepercentage=8 and sievesize=2000000 for some time now. PPS and chains/min dropped about 50% with the introduction of this performance problem. I'll try using the default sievesize.

[paulthetafy]

Also I found the reason for the performance regression. The latest code seems to get stuck on using too low round primorials.

The performance regression should be fixed by latest commit on bitbucket.

I'm still getting poor performance with the latest commit, it doesn't look like the fix helped at all.

Can you be more specific how your performance is poor? Are you looking at primes/sec, chain/min, block rate or something else? Also remember to not compare any numbers against previous network difficulties.

EDIT: It seems you may be right. Most of my own tests are still showing poor performance.
EDIT2: Large sieve sizes trigger pretty much the same performance bug.

mikealh, I'm seeing OK performance with this in terms of PPS but haven't checked the chains.  im using a 2M sieve.  Is the bug triggered by a bigger sieve?

[mikaelh]

mikealh, I'm seeing OK performance with this in terms of PPS but haven't checked the chains.  im using a 2M sieve.  Is the bug triggered by a bigger sieve?

Well, at least on my system a bigger sieve size seems to change the timings in the code so that the dynamic adjustment system starts doing silly things.

[mikaelh]

-hp8 is finally out!

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.

Links to downloads are on the first page. This release was delayed by a few bugs but it's finally here. Many improvements and fixes were included in this one. My own benchmarks show that block rate is nearly doubled compared to -hp7 on testnet. Performance on mainnet is also looking really good.

There's a new tuning parameter called -roundsievepercentage. You shouldn't need to touch this normally. Optimal value for mainnet seems to be around 30%. For testnet it's around 20% for some reason. The round primorial is adjusted based on this parameter. Smaller percentage means a bigger round primorial. Bigger round primorial in turn means that primes are more probable but the numbers will also get bigger which will slows down the testing.

Bigger sieve sizes seem to have suffered a performance hit with this release. I suggest starting with the default size.

[8bitPunk]

-hp8 is finally out!

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.

Links to downloads are on the first page. This release was delayed by a few bugs but it's finally here. Many improvements and fixes were included in this one. My own benchmarks show that block rate is nearly doubled compared to -hp7 on testnet. Performance on mainnet is also looking really good.

There's a new tuning parameter called -roundsievepercentage. You shouldn't need to touch this normally. Optimal value for mainnet seems to be around 30%. For testnet it's around 20% for some reason. The round primorial is adjusted based on this parameter. Smaller percentage means a bigger round primorial. Bigger round primorial in turn means that primes are more probable but the numbers will also get bigger which will slows down the testing.

Bigger sieve sizes seem to have suffered a performance hit with this release. I suggest starting with the default size.

Thanks mikaelh... Is there anything similar to Sunny's original gensieveroundlimitms as a fallback to limit the total time spent on a round?

[reb0rn21]

Tnx for the hard work, donated 3 XPM

I had luck with 3.6M sieve on HP7, will test 2M now on my haswell

at the end chainspermin say 1M sieve give most 11-13

[hasle2]

Does anyone know if I need to run any commands when transferring wallets from one computer to another? I sent a few to one computer and then used that to transfer to my main wallet on another machine. It worked the first one or two times but the third transfer seems to have disappeared. The old wallet shows a balance of 0 while the main wallet has not received any coins. It's been around an hour now, every other transfer has taken seconds.

To transfer the wallet I would shut down primecoind, replace the old empty wallet with the new one and start primecoind again.

[Tuck Fheman]

nice & thanks again!

These are the highest PPS I've seen in awhile ever on mainnet (or testnet). [ i7/860/3.22/Win7/64 ]

these were fetched using different settings. "best"(?) results are at the bottom.

Notes : I've been able to go as high as 8000000 (not since HP3) and 33% sievepercentage (never before). However, those higher settings seemed to lower PPS/CPM. Since I'm not finding blocks, I can't say whether that's good or bad.

Lowering roundsievepercentage to 20 seemed to increase CPM.  To early to tell.

"roundsievepercentage" : 40,  has yielded the steadiest/near top results with less variance (so far). I'm not sure how dependent it is upon sievesize (which is currently at 200000)


Updated as I find higher results / better settings(?) ...

SPOILER : 100000 is fastest I've ever seen. Whether that relates to more blocks or not, someone who's finding blocks tell us.

Below are the "best"(?) settings for CPM/PPS (on my box, see above).

ChainSpermin settings ...

"sievepercentage" : 10,
"sievesize" : 100000,
"roundsievepercentage" : 20,30,40 <--- try each one.

It would be cool if someone w/a big operation going could verify these settings find blocks as well as they (CPM/PPS) indicate they might. I only have one box here and it's rather old (see above).

Code:

{
"blocks" : 83276,
"chainspermin" : 2,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 9.26852113,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"roundsievepercentage" : 30,
"primespersec" : 1404,
"pooledtx" : 0,
"sievepercentage" : 10,
"sievesize" : 6144000,
"testnet" : false
}



{
"blocks" : 83228,
"chainspermin" : 5,
"currentblocksize" : 2181,
"currentblocktx" : 2,
"difficulty" : 9.26978731,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"roundsievepercentage" : 30,
"primespersec" : 1732,
"pooledtx" : 2,
"sievepercentage" : 10,
"sievesize" : 4000000,
"testnet" : false
}



{
"blocks" : 83214,
"chainspermin" : 4,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 9.26970702,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"roundsievepercentage" : 30,
"primespersec" : 2185,
"pooledtx" : 0,
"sievepercentage" : 10,
"sievesize" : 2000000,
"testnet" : false
}

{
"blocks" : 83226,
"chainspermin" : 4,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 9.26941282,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"roundsievepercentage" : 30,
"primespersec" : 2677,
"pooledtx" : 0,
"sievepercentage" : 14,
"sievesize" : 800000,
"testnet" : false
}

{
"blocks" : 83220,
"chainspermin" : 6,
"currentblocksize" : 2343,
"currentblocktx" : 2,
"difficulty" : 9.26957196,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"roundsievepercentage" : 30,
"primespersec" : 3046,
"pooledtx" : 2,
"sievepercentage" : 8,
"sievesize" : 800000,
"testnet" : false
}

{
"blocks" : 83188,
"chainspermin" : 2,
"currentblocksize" : 1384,
"currentblocktx" : 2,
"difficulty" : 9.26898366,
"errors" : "",
"generate" : true,
"genproclimit" : 6,
"roundsievepercentage" : 30,
"primespersec" : 3229,
"pooledtx" : 2,
"sievepercentage" : 10,
"sievesize" : 1000000,
"testnet" : false
}


{
"blocks" : 83189,
"chainspermin" : 9,
"currentblocksize" : 2270,
"currentblocktx" : 3,
"difficulty" : 9.26901996,
"errors" : "",
"generate" : true,
"genproclimit" : 6,
"roundsievepercentage" : 30,
"primespersec" : 2793,
"pooledtx" : 3,
"sievepercentage" : 10,
"sievesize" : 1000000,
"testnet" : false
}



{
"blocks" : 83282,
"chainspermin" : 8,
"currentblocksize" : 1159,
"currentblocktx" : 1,
"difficulty" : 9.26784396,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"roundsievepercentage" : 20,
"primespersec" : 4431,
"pooledtx" : 1,
"sievepercentage" : 8,
"sievesize" : 100000,
"testnet" : false
}


{
"blocks" : 83270,
"chainspermin" : 12,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 9.26927489,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"roundsievepercentage" : 40, <--
"primespersec" : 3686,
"pooledtx" : 0,
"sievepercentage" : 8,
"sievesize" : 200000,
"testnet" : false
}


{
"blocks" : 83194,
"chainspermin" : 10,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 9.26869631,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"roundsievepercentage" : 30,
"primespersec" : 2624,
"pooledtx" : 0,
"sievepercentage" : 8,
"sievesize" : 1000000,
"testnet" : false
}


{
"blocks" : 83260,
"chainspermin" : 7,
"currentblocksize" : 1454,
"currentblocktx" : 1,
"difficulty" : 9.26930588,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"roundsievepercentage" : 10,   <----
"primespersec" : 3658,
"pooledtx" : 1,
"sievepercentage" : 10,
"sievesize" : 200000,
"testnet" : false
}


{
"blocks" : 83202,
"chainspermin" : 13,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 9.26930326,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"roundsievepercentage" : 30,
"primespersec" : 2739,
"pooledtx" : 0,
"sievepercentage" : 8,
"sievesize" : 1000000,
"testnet" : false
}

{
"blocks" : 83216,
"chainspermin" : 9,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 9.26956218,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"roundsievepercentage" : 30,
"primespersec" : 3533,
"pooledtx" : 0,
"sievepercentage" : 10,
"sievesize" : 800000,
"testnet" : false
}



{
"blocks" : 83293,
"chainspermin" : 11,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 9.26723182,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"roundsievepercentage" : 25,
"primespersec" : 3785,
"pooledtx" : 0,
"sievepercentage" : 10,
"sievesize" : 100000,
"testnet" : false
}


{
"blocks" : 83246,
"chainspermin" : 13,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 9.26922071,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"roundsievepercentage" : 20,
"primespersec" : 4221,
"pooledtx" : 0,
"sievepercentage" : 8,
"sievesize" : 100000,
"testnet" : false
}


{
"blocks" : 83238,
"chainspermin" : 5,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 9.26953423,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"roundsievepercentage" : 30,
"primespersec" : 5045,   <----- NEVER SEEN ABOVE 3500 or so.
"pooledtx" : 0,
"sievepercentage" : 10,
"sievesize" : 100000,
"testnet" : false
}


{
"blocks" : 83240,
"chainspermin" : 9,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 9.26970094,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"roundsievepercentage" : 30,
"primespersec" : 4984,
"pooledtx" : 0,
"sievepercentage" : 10,
"sievesize" : 100000,
"testnet" : false
}



{
"blocks" : 83362,
"chainspermin" : 14,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 9.26707476,
"errors" : "",
"generate" : true,
"genproclimit" : 7,
"roundsievepercentage" : 30,
"primespersec" : 4065,
"pooledtx" : 0,
"sievepercentage" : 10,
"sievesize" : 100000,
"testnet" : false
}