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

[mikaelh]

The nL1CacheElements constant was not meant to be changed and there's a good reason for that. nL1CacheElements needs to be a multiple of 64 on a 64-bit platform (or a multiple of 32 on a 32-bit platform). Otherwise the sieve code will start misbehaving which seems to be what razibuzouzou is seeing. The sieve will start producing false candidates which will distort the metrics. The tests/h is the number of candidates produced by the sieve which is directly impacted. The chains/day estimate relies on tests/h being accurate so that will also be heavily impacted.

With the latest version, there could also be a small negative impact on block rate if the sieve is misbehaving. The false candidates will always be marked as bi-twin candidates. If it in reality is a candidate of another type, it will not get recognized properly.

Summary: Don't touch nL1CacheElements unless you know exactly what you're doing.

[paulthetafy]

The nL1CacheElements constant was not meant to be changed and there's a good reason for that. nL1CacheElements needs to be a multiple of 64 on a 64-bit platform (or a multiple of 32 on a 32-bit platform). Otherwise the sieve code will start misbehaving which seems to be what razibuzouzou is seeing. The sieve will start producing false candidates which will distort the metrics. The tests/h is the number of candidates produced by the sieve which is directly impacted. The chains/day estimate relies on tests/h being accurate so that will also be heavily impacted.

With the latest version, there could also be a small negative impact on block rate if the sieve is misbehaving. The false candidates will always be marked as bi-twin candidates. If it in reality is a candidate of another type, it will not get recognized properly.

Summary: Don't touch nL1CacheElements unless you know exactly what you're doing.

mikeal, what about using values that ARE a multiple of both 64 and 32 then?  Is that safe and will it yield improved performance if done correctly?

[mikaelh]

The nL1CacheElements constant was not meant to be changed and there's a good reason for that. nL1CacheElements needs to be a multiple of 64 on a 64-bit platform (or a multiple of 32 on a 32-bit platform). Otherwise the sieve code will start misbehaving which seems to be what razibuzouzou is seeing. The sieve will start producing false candidates which will distort the metrics. The tests/h is the number of candidates produced by the sieve which is directly impacted. The chains/day estimate relies on tests/h being accurate so that will also be heavily impacted.

With the latest version, there could also be a small negative impact on block rate if the sieve is misbehaving. The false candidates will always be marked as bi-twin candidates. If it in reality is a candidate of another type, it will not get recognized properly.

Summary: Don't touch nL1CacheElements unless you know exactly what you're doing.

mikeal, what about using values that ARE a multiple of both 64 and 32 then?  Is that safe and will it yield improved performance if done correctly?

If you use multiples of 64 (or 32), then that should work in theory. I haven't really tested that exhaustively though. I would expect minimal gains from adjusting it in most cases.

[paulthetafy]

The nL1CacheElements constant was not meant to be changed and there's a good reason for that. nL1CacheElements needs to be a multiple of 64 on a 64-bit platform (or a multiple of 32 on a 32-bit platform). Otherwise the sieve code will start misbehaving which seems to be what razibuzouzou is seeing. The sieve will start producing false candidates which will distort the metrics. The tests/h is the number of candidates produced by the sieve which is directly impacted. The chains/day estimate relies on tests/h being accurate so that will also be heavily impacted.

With the latest version, there could also be a small negative impact on block rate if the sieve is misbehaving. The false candidates will always be marked as bi-twin candidates. If it in reality is a candidate of another type, it will not get recognized properly.

Summary: Don't touch nL1CacheElements unless you know exactly what you're doing.

mikeal, what about using values that ARE a multiple of both 64 and 32 then?  Is that safe and will it yield improved performance if done correctly?

If you use multiples of 64 (or 32), then that should work in theory. I haven't really tested that exhaustively though. I would expect minimal gains from adjusting it in most cases.

thanks mikael, I tried values ~100000 higher and lower (but multiples of 64/32) and saw decreased performance both ways, so 200000 seems optimal for now.  Shame, I was starting to think I could get 3x performance then

[mumus]

The nL1CacheElements constant was not meant to be changed and there's a good reason for that. nL1CacheElements needs to be a multiple of 64 on a 64-bit platform (or a multiple of 32 on a 32-bit platform). Otherwise the sieve code will start misbehaving which seems to be what razibuzouzou is seeing. The sieve will start producing false candidates which will distort the metrics. The tests/h is the number of candidates produced by the sieve which is directly impacted. The chains/day estimate relies on tests/h being accurate so that will also be heavily impacted.

With the latest version, there could also be a small negative impact on block rate if the sieve is misbehaving. The false candidates will always be marked as bi-twin candidates. If it in reality is a candidate of another type, it will not get recognized properly.

Summary: Don't touch nL1CacheElements unless you know exactly what you're doing.

Mikael, thank you for the clarification. Indeed after checking the code I found the reason why it has to be a multiple of 64/32. It's a shame I didn't checked this before.
Anyway I've run some more tests and using the default settings of the primecoin client there was no significant gain for different nL1CacheElements, but in the moment the sieve size and the sieve percentage was raised  the nL1CacheElements size had more affect. For example with sievesize=2000000 and sievepercentage=50 a higher nL1CacheElements (1056000) speeds up the Wave by ~30%. (my CPU is i7)
In any case because 50% is probably not the optimal sievepercentage this measurement is less relevant.

[mumus]

The nL1CacheElements constant was not meant to be changed and there's a good reason for that. nL1CacheElements needs to be a multiple of 64 on a 64-bit platform (or a multiple of 32 on a 32-bit platform). Otherwise the sieve code will start misbehaving which seems to be what razibuzouzou is seeing. The sieve will start producing false candidates which will distort the metrics. The tests/h is the number of candidates produced by the sieve which is directly impacted. The chains/day estimate relies on tests/h being accurate so that will also be heavily impacted.

With the latest version, there could also be a small negative impact on block rate if the sieve is misbehaving. The false candidates will always be marked as bi-twin candidates. If it in reality is a candidate of another type, it will not get recognized properly.

Summary: Don't touch nL1CacheElements unless you know exactly what you're doing.

Mikael, thank you for the clarification. Indeed after checking the code I found the reason why it has to be a multiple of 64/32. It's a shame I didn't checked this before.
Anyway I've run some more tests and using the default settings of the primecoin client there was no significant gain for different nL1CacheElements, but in the moment the sieve size and the sieve percentage was raised  the nL1CacheElements size had more affect. For example with sievesize=2000000 and sievepercentage=50 a higher nL1CacheElements (1056000) speeds up the Wave by ~30%. (my CPU is i7)
In any case because 50% is probably not the optimal sievepercentage this measurement is less relevant.

BTW: I'm compiling the 64bit version of jhPrimeminer under Windows with Visual Studio, where the size of 'unsigned long' is 32bit and not 64bit like in Linux (GNU). I've tried replacing the "unsigned long" with uint64_t (unsigned long long)  but it makes the Wave function run slower ( ~15-25%). I'm thinking maybe it worth a try to replace the "unsigned long' to uint32 in the Wave() function in primecoin (HP9) client where the nL1CacheElements  is also used.
Does it makes sense what I'm talking about?

[mikaelh]

The nL1CacheElements constant was not meant to be changed and there's a good reason for that. nL1CacheElements needs to be a multiple of 64 on a 64-bit platform (or a multiple of 32 on a 32-bit platform). Otherwise the sieve code will start misbehaving which seems to be what razibuzouzou is seeing. The sieve will start producing false candidates which will distort the metrics. The tests/h is the number of candidates produced by the sieve which is directly impacted. The chains/day estimate relies on tests/h being accurate so that will also be heavily impacted.

With the latest version, there could also be a small negative impact on block rate if the sieve is misbehaving. The false candidates will always be marked as bi-twin candidates. If it in reality is a candidate of another type, it will not get recognized properly.

Summary: Don't touch nL1CacheElements unless you know exactly what you're doing.

Mikael, thank you for the clarification. Indeed after checking the code I found the reason why it has to be a multiple of 64/32. It's a shame I didn't checked this before.
Anyway I've run some more tests and using the default settings of the primecoin client there was no significant gain for different nL1CacheElements, but in the moment the sieve size and the sieve percentage was raised  the nL1CacheElements size had more affect. For example with sievesize=2000000 and sievepercentage=50 a higher nL1CacheElements (1056000) speeds up the Wave by ~30%. (my CPU is i7)
In any case because 50% is probably not the optimal sievepercentage this measurement is less relevant.

BTW: I'm compiling the 64bit version of jhPrimeminer under Windows with Visual Studio, where the size of 'unsigned long' is 32bit and not 64bit like in Linux (GNU). I've tried replacing the "unsigned long" with uint64_t (unsigned long long)  but it makes the Wave function run slower ( ~15-25%). I'm thinking maybe it worth a try to replace the "unsigned long' to uint32 in the Wave() function in primecoin (HP9) client where the nL1CacheElements  is also used.
Does it makes sense what I'm talking about?

Well, it's good to know that long is always 32-bits in Visual Studio. I haven't really worked with that compiler. One unfortunate side-effect of that is being unable to pass 64-bit values directly to GMP/MPIR because the interface uses unsigned longs.

I think 64-bits integer are better for this part of the code because it performs logical operations on bits.
Thus, you process twice more bits with 64-bits integers than with 32-bits.
I think you may have a performance loss because Visual Studio does not vectorize 64-bits integers operations very well.

Yup, I also suspect that the Visual Studio compiler isn't optimizing properly there. But I haven't looked at the generated code.

Back to the nL1CacheElements constant. I am having a small (>3%) but clear performance improvement with 256000 (chainsperday increases and primesperday is preserved).
Tested and confirmed on two different architectures (AMD & Intel).
I know it's micro-optimization garbage (sorry!), but Mikaelh, does this value sound good to you ?

Well, I did check that most Intel processors have a 32 kB L1 data cache while AMD processors typically have a 64 kB data cache. 256000 is pretty much pushing the L1 cache to its limits on Intel CPUs. If it also shows good performance in my testing, I will probably incorporate that change. The annoying issue with 256000 is that it doesn't divide 1M (sieve size) evenly.

I have also considered discovering the L1 cache size automatically and adjusting the parameters based on that. The problem with that is that I don't have a lot of CPUs to test on.

[Lyddite]

In case you are interested in the validity of the chains per day metric, with the following setup running on 9 identical machines I managed 8 chains over 24 hours.

8/9=0.8888 chains per day.

I would say, close enough for government work in this case.

Code:

    "blocks" : 105938,
    "chainspermin" : 3,
    "chainsperday" : 0.92945471,
    "currentblocksize" : 1000,
    "currentblocktx" : 0,
    "difficulty" : 9.59519291,
    "errors" : "",
    "generate" : true,
    "genproclimit" : -1,
    "roundsievepercentage" : 70,
    "primespersec" : 1707,
    "pooledtx" : 0,
    "sievepercentage" : 10,
    "sievesize" : 1100000,
    "testnet" : false

[monsterer]

hp9 gives me the following compile error on centos6 (the previous version compiled ok):

"In function `CKey::Verify(uint256, std::vector<unsigned char, std::allocator<unsigned char> > const&)':
/root/primecoin-0.1.2-hp9/src/key.cpp:376: undefined reference to `ECDSA_verify'
obj/key.o: In function `CKey::SetCompressedPubKey(bool)':
/root/primecoin-0.1.2-hp9/src/key.cpp:125: undefined reference to `EC_KEY_set_conv_form'"

[gigawatt]

In case you are interested in the validity of the chains per day metric, with the following setup running on 9 identical machines I managed 8 chains over 24 hours.

8/9=0.8888 chains per day.

I would say, close enough for government work in this case.

Code:

    "blocks" : 105938,
    "chainspermin" : 3,
    "chainsperday" : 0.92945471,
    "currentblocksize" : 1000,
    "currentblocktx" : 0,
    "difficulty" : 9.59519291,
    "errors" : "",
    "generate" : true,
    "genproclimit" : -1,
    "roundsievepercentage" : 70,
    "primespersec" : 1707,
    "pooledtx" : 0,
    "sievepercentage" : 10,
    "sievesize" : 1100000,
    "testnet" : false

Lucky you then.  I have 8 machines running at ~1.0 chains/day + a few spare machines on the side.  I got 3 blocks in the last 24 hours. 

[torbank]

hp9 gives me the following compile error on centos6 (the previous version compiled ok):

"In function `CKey::Verify(uint256, std::vector<unsigned char, std::allocator<unsigned char> > const&)':
/root/primecoin-0.1.2-hp9/src/key.cpp:376: undefined reference to `ECDSA_verify'
obj/key.o: In function `CKey::SetCompressedPubKey(bool)':
/root/primecoin-0.1.2-hp9/src/key.cpp:125: undefined reference to `EC_KEY_set_conv_form'"

Is it a fresh install of CentOS?

If so, you'll need this step:

Step 2b. Compiling OpenSSL (for CentOS users)

This step is only required if you're using CentOS. Red Hat has removed support for elliptic curve cryptography from the OpenSSL it supplies.

Code:
cd
rm -rf openssl-1.0.1e.tar.gz openssl-1.0.1e
wget http://ftp://ftp.pca.dfn.de/pub/tools/net/openssl/source/openssl-1.0.1e.tar.gz
tar xzvf openssl-1.0.1e.tar.gz
cd openssl-1.0.1e
./config shared --prefix=/usr/local --libdir=lib
make
sudo make install

https://bitcointalk.org/index.php?topic=259022.0

[Ethera]

In case you are interested in the validity of the chains per day metric, with the following setup running on 9 identical machines I managed 8 chains over 24 hours.

8/9=0.8888 chains per day.

I would say, close enough for government work in this case.

Code:

    "blocks" : 105938,
    "chainspermin" : 3,
    "chainsperday" : 0.92945471,
    "currentblocksize" : 1000,
    "currentblocktx" : 0,
    "difficulty" : 9.59519291,
    "errors" : "",
    "generate" : true,
    "genproclimit" : -1,
    "roundsievepercentage" : 70,
    "primespersec" : 1707,
    "pooledtx" : 0,
    "sievepercentage" : 10,
    "sievesize" : 1100000,
    "testnet" : false

Lucky you then.  I have 8 machines running at ~1.0 chains/day + a few spare machines on the side.  I got 3 blocks in the last 24 hours. 

"blocks" : 106059,
"chainspermin" : 21,
"chainsperday" : 2.44443307,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 9.59809953,

cant say that i find 2 blocks per machine per day.. i am lucky to hit 4 blocks per all 6 mashines per day (All are identical)

[Lyddite]

In case you are interested in the validity of the chains per day metric, with the following setup running on 9 identical machines I managed 8 chains over 24 hours.

8/9=0.8888 chains per day.

I would say, close enough for government work in this case.

Lucky you then.  I have 8 machines running at ~1.0 chains/day + a few spare machines on the side.  I got 3 blocks in the last 24 hours. 

Hmmm...hopefully 13 blocks tomorrow...  

Here's a useful oneliner if you want to see exactlya sorted list of when your blocks were found and if you are not comfortable with reading times and dates as
seconds since 1970... UTC.  

Code:

primecoind listtransactions | grep blocktime |  sed -e "s/.* : //" -e "s/,//" | sort | xargs -n 1 -I '{}' date --date=@'{}'

[redphlegm]

In case you are interested in the validity of the chains per day metric, with the following setup running on 9 identical machines I managed 8 chains over 24 hours.

8/9=0.8888 chains per day.

I would say, close enough for government work in this case.

Code:

    "blocks" : 105938,
    "chainspermin" : 3,
    "chainsperday" : 0.92945471,
    "currentblocksize" : 1000,
    "currentblocktx" : 0,
    "difficulty" : 9.59519291,
    "errors" : "",
    "generate" : true,
    "genproclimit" : -1,
    "roundsievepercentage" : 70,
    "primespersec" : 1707,
    "pooledtx" : 0,
    "sievepercentage" : 10,
    "sievesize" : 1100000,
    "testnet" : false

Lucky you then.  I have 8 machines running at ~1.0 chains/day + a few spare machines on the side.  I got 3 blocks in the last 24 hours. 

"blocks" : 106059,
"chainspermin" : 21,
"chainsperday" : 2.44443307,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 9.59809953,

cant say that i find 2 blocks per machine per day.. i am lucky to hit 4 blocks per all 6 mashines per day (All are identical)

If you set up one and cloned it, you may be dealing with conflicting / insufficient entropy.

[gigawatt]

"blocks" : 106059,
"chainspermin" : 21,
"chainsperday" : 2.44443307,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 9.59809953,

cant say that i find 2 blocks per machine per day.. i am lucky to hit 4 blocks per all 6 mashines per day (All are identical)

If you set up one and cloned it, you may be dealing with conflicting / insufficient entropy.

Quick and easy fix:

Code:

apt-get install haveged -y
update-rc.d haveged defaults
service haveged start

[paulthetafy]

You guys are confusing finding chains for finding blocks. Having a chains/d of 1 does NOT imply you should find a block a day on average.

[Trillium]

You guys are confusing finding chains for finding blocks. Having a chains/d of 1 does NOT imply you should find a block a day on average.

Right, as has been pointed out, chainsperday is a count of how many chains should meet the integer difficulty requirement, not considering the fractional difficulty requirement that must also be met.

Simple example:

If your chains per day was 1.0 and diff was 9.0100 then you will probably find 1 block per day on average.
If your chains per day was 1.0 and diff was 9.9985 then you probably won't find a block

Please correct me if my understanding is wrong...

However, like with any solo mining, you are still subject to variance ("luck"). You could find 4 blocks the first day you mine then find nothing for a week or more... etc

[Tamis]

I have 50 vps running with chainsperday ranging from 1.18 to 0.9 and I find between 15 to 21 blocks per day.
They were not cloned so entropy is not a problem.

[96redformula]

I have 50 vps running with chainsperday going from 1.18 to 0.9 and I find between 15 to 21 blocks per day.
They were not cloned so entropy is not a problem.

50 VPS with how many cores?  Digital Ocean?

[jimoc]

I have 50 vps running with chainsperday going from 1.18 to 0.9 and I find between 15 to 21 blocks per day.
They were not cloned so entropy is not a problem.

50 VPS with how many cores?  Digital Ocean?

If you have cloned instances running is there a way to fix the lack of entropy?
I've got 10 AWS instances running but not seen any blocks for 3 days and they were all launched from the same AMI.