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

[gateway]

-hp5 released!

This version adds a fast 32-bit routine for inverting numbers. I did some other small performance improvements to the sieve as well. Nothing really big though. Only a 2% improvement in my benchmark.

Official backup repository is now on bitbucket:
https://bitbucket.org/mikaelh/primecoin-hp

But please download the source code from SourceForge if you can.

aaaand compiled and running

Can anyone make a windows build please?

[1714031715]

1714031715

[1714031715]

1714031715

[1714031715]

1714031715

[1714031715]

1714031715

[ivanlabrie]

-hp5 released!

This version adds a fast 32-bit routine for inverting numbers. I did some other small performance improvements to the sieve as well. Nothing really big though. Only a 2% improvement in my benchmark.

Official backup repository is now on bitbucket:
https://bitbucket.org/mikaelh/primecoin-hp

But please download the source code from SourceForge if you can.

aaaand compiled and running

Can anyone make a windows build please?

There's one in the first page man.

[gateway]

anyone got this running on osx?

It compiles fine but when running after a few sec it quits

user$ Assertion failed: (pfork != NULL), function SetBestChain, file main.cpp, line 1722.

[gateway]

stopping the client on my ubuntu 12.x box spit this error out

fyi

gateway@a:~/work/primecoin-hp/src$ ./primecoind stop
Primecoin server stopping
gateway@a:~/work/primecoin-hp/src$ primecoind: /usr/include/boost/thread/pthread/pthread_mutex_scoped_lock.hpp:26: boost::pthread::pthread_mutex_scoped_lock::pthread_mutex_scoped_lock(pthread_mutex_t*): Assertion `!pthread_mutex_lock(m)' failed.

[jubalix]

what happened went from 14K pps to 6K pps accross all machines, did some sort of botnet come on? bug in hp5?

[Koooooj]

Just wanted to say great miner!  I feel like this is probably the most optimized miner on the market right now.  Looking over the source code of the original miner and yours I think I see a way to make the miner (potentially much) faster from a mathematical standpoint rather than a code-optimization standpoint.  My optimization centers around the Primorial and the loop that occurs in main.cpp on line 4622.

Before getting into the code, it is important to realize why a primorial is helpful (if you already understand this, skip this paragraph).  With numbers on the order of 2²⁵⁶ there is about a 1 in 177 chance that a random number is prime.  If you select 8 random numbers, then, the odds of all of them being prime is about 1 in 1 quintillion--impractically low.  If you limit your search to only odd numbers, though, the odds shoot up tremendously.  Further limiting your search to numbers not divisible by 3, 5, 7, and so on can cause the odds of finding a prime number to become much, much better.  If the hash value is divisible by lots of these small numbers then multiples of that hash ± 1 will not be divisible by any of those numbers.  Thus, it is convenient to use a hash that is already a multiple of 2 * 3 * 5 * 7 * ... as it will produce far more primes than another hash.

As I understand the aforementioned loop, the program is searching for a hash that is divisible by a primorial.  Each iteration of this loop requires a hash to be generated as it increments the nonce value.  In the present form the primorail is of degree 7 (line 4579: static const unsigned int nPrimorialHashFactor = 7).  I suspect that this value is carefully chosen and it's probably ideal with the way that it is written.  However, I think there's an additional step that can be added to make the process much faster.  Increasing the degree of the primorial is incredibly expensive as it gets larger, since adding the 8th prime requires 19 times as many hashes to be checked; the 9th prime requires 23 times as many, and so on.  There is another way, though.

Prime origins are required to be in the form O = H * N where O is the origin, H is the hash, and N is any integer; H is selected to be divisible by p#7 (the primorial shown above).  If we extend this to O = H * N * P₂ where P₂ is 19 * 23 * 29 * ... * 51--a product of primes starting after the last prime used in the existing search--then the checked origin is still valid (an integer times an integer is still an integer).  This grants the benefits of searching with a higher degree primorial while not requiring a longer search for a working hash.  

Nothing is free, though, as this method inflates the size of the primes to be checked.  If the fast modular exponentiation is implemented through the same method as is used on the Fermat Primality Test Wikipedia page then the algorithmic efficiency is O(log²(n) * log(log(n)) * log(log(log(n))) ).  There should be some sweet spot of how large of a primorial to use where the increased frequency of primes more than offsets the extra time required for the fast modular exponentiation.  It's possible that the sweet spot is 0 extra primes, but I think it's worth looking into.

[gateway]

64bit hp5 version crashes after a bit on my windows 7 box.. 64 bit.. with this..

[forsetifox]

64bit hp5 version crashes after a bit on my windows 7 box.. 64 bit.. with this..

I've had the hp4 client do this once in like 72 hours. Just restart.

[Plazma]

64bit hp5 version crashes after a bit on my windows 7 box.. 64 bit.. with this..

This is error from older versions. It crashed on my main PC pretty often especially if I'm doing something else like gaming or watching on XBMC.
So far 0 crashes on the dedicated mining rigs.

[blastbob]

64bit hp5 version crashes after a bit on my windows 7 box.. 64 bit.. with this..

I've had the hp4 client do this once in like 72 hours. Just restart.

OP knows about the error but wants to optimize more before looking into it.

[superfluouso]

Do we need to adjust the sievesize in accordance to upcoming increase in difficulty?

Was the optimal sieve size ever determined?  What is everyone using with hp5?

[noodle_dam]

What is the best way to get an hp build working on OS X?

[gateway]

64bit hp5 version crashes after a bit on my windows 7 box.. 64 bit.. with this..

I've had the hp4 client do this once in like 72 hours. Just restart.

yea this happens with in about 5-10 min of launching.. need to find hp4 which worked fine..

[dudeguy]

Just wanted to say great miner!  I feel like this is probably the most optimized miner on the market right now.  Looking over the source code of the original miner and yours I think I see a way to make the miner (potentially much) faster from a mathematical standpoint rather than a code-optimization standpoint.  My optimization centers around the Primorial and the loop that occurs in main.cpp on line 4622.

Before getting into the code, it is important to realize why a primorial is helpful (if you already understand this, skip this paragraph).  With numbers on the order of 2²⁵⁶ there is about a 1 in 177 chance that a random number is prime.  If you select 8 random numbers, then, the odds of all of them being prime is about 1 in 1 quintillion--impractically low.  If you limit your search to only odd numbers, though, the odds shoot up tremendously.  Further limiting your search to numbers not divisible by 3, 5, 7, and so on can cause the odds of finding a prime number to become much, much better.  If the hash value is divisible by lots of these small numbers then multiples of that hash ± 1 will not be divisible by any of those numbers.  Thus, it is convenient to use a hash that is already a multiple of 2 * 3 * 5 * 7 * ... as it will produce far more primes than another hash.

As I understand the aforementioned loop, the program is searching for a hash that is divisible by a primorial.  Each iteration of this loop requires a hash to be generated as it increments the nonce value.  In the present form the primorail is of degree 7 (line 4579: static const unsigned int nPrimorialHashFactor = 7).  I suspect that this value is carefully chosen and it's probably ideal with the way that it is written.  However, I think there's an additional step that can be added to make the process much faster.  Increasing the degree of the primorial is incredibly expensive as it gets larger, since adding the 8th prime requires 19 times as many hashes to be checked; the 9th prime requires 23 times as many, and so on.  There is another way, though.

Prime origins are required to be in the form O = H * N where O is the origin, H is the hash, and N is any integer; H is selected to be divisible by p#7 (the primorial shown above).  If we extend this to O = H * N * P₂ where P₂ is 19 * 23 * 29 * ... * 51--a product of primes starting after the last prime used in the existing search--then the checked origin is still valid (an integer times an integer is still an integer).  This grants the benefits of searching with a higher degree primorial while not requiring a longer search for a working hash.  

Nothing is free, though, as this method inflates the size of the primes to be checked.  If the fast modular exponentiation is implemented through the same method as is used on the Fermat Primality Test Wikipedia page then the algorithmic efficiency is O(log²(n) * log(log(n)) * log(log(log(n))) ).  There should be some sweet spot of how large of a primorial to use where the increased frequency of primes more than offsets the extra time required for the fast modular exponentiation.  It's possible that the sweet spot is 0 extra primes, but I think it's worth looking into.

This!

[atomium]

when would you use the x86 vs x64 version? I have a quadcore laptop running windows 7.

Right now I have the x86 running, is this correct for fastest performance? what would be the difference running 86 and 64?

[redphlegm]

What is the best way to get an hp build working on OS X?

Having toyed with it for hours, I can conclusively say that installing VMWare Fusion with an image of Ubuntu and compiling / running it on there yields the best results. I don't know why, it just does. Natively, compiled in Mountain Lion, I get about half the performance from the same build compiled in the VM.

I hope helps you out.

[AstroKev]

My optimization centers around the Primorial and the loop that occurs in main.cpp on line 4622.

Flat profile:

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
 time   seconds   seconds    calls  ms/call  ms/call  name   
 79.89     45.84    45.84     5698     8.04     8.04  CSieveOfEratosthenes::Weave()
 10.28     51.74     5.90     5694     1.04     1.04  CSieveOfEratosthenes::CSieveOfEratosthenes(unsigned int, unsigned int, __gmp_expr<__m
pz_struct [1], __mpz_struct [1]>&, __gmp_expr<__mpz_struct [1], __mpz_struct [1]>&, CBlockIndex*)
  9.03     56.92     5.18    62611     0.08     0.91  MineProbablePrimeChain(CBlock&, __gmp_expr<__mpz_struct [1], __mpz_struct [1]>&, bool
&, unsigned int&, unsigned int&, unsigned int&, unsigned int&, unsigned int&, __gmp_expr<__mpz_struct [1], __mpz_struct [1]>&)
  0.16     57.01     0.09  7019519     0.00     0.00  FermatProbablePrimalityTest(__gmp_expr<__mpz_struct [1], __mpz_struct [1]> const&, un
signed int&)

Without a doubt, the Weave function is the slowest of them all.  I haven't yet dissected it (and won't really claim to understand what it's trying to do yet), but since this ultimately is buried way below the void static BitcoinMiner(CWallet *pwallet)
 function, I'm guessing that anythign that would result in fewer calls to MineProbablePrimeChain would be a net very good thing.  OTOH, further optimizing Weave still looks like a good bet.

[RandyFolds]

Just wanted to say great miner!  I feel like this is probably the most optimized miner on the market right now.  Looking over the source code of the original miner and yours I think I see a way to make the miner (potentially much) faster from a mathematical standpoint rather than a code-optimization standpoint.  My optimization centers around the Primorial and the loop that occurs in main.cpp on line 4622.

Before getting into the code, it is important to realize why a primorial is helpful (if you already understand this, skip this paragraph).  With numbers on the order of 2²⁵⁶ there is about a 1 in 177 chance that a random number is prime.  If you select 8 random numbers, then, the odds of all of them being prime is about 1 in 1 quintillion--impractically low.  If you limit your search to only odd numbers, though, the odds shoot up tremendously.  Further limiting your search to numbers not divisible by 3, 5, 7, and so on can cause the odds of finding a prime number to become much, much better.  If the hash value is divisible by lots of these small numbers then multiples of that hash ± 1 will not be divisible by any of those numbers.  Thus, it is convenient to use a hash that is already a multiple of 2 * 3 * 5 * 7 * ... as it will produce far more primes than another hash.

As I understand the aforementioned loop, the program is searching for a hash that is divisible by a primorial.  Each iteration of this loop requires a hash to be generated as it increments the nonce value.  In the present form the primorail is of degree 7 (line 4579: static const unsigned int nPrimorialHashFactor = 7).  I suspect that this value is carefully chosen and it's probably ideal with the way that it is written.  However, I think there's an additional step that can be added to make the process much faster.  Increasing the degree of the primorial is incredibly expensive as it gets larger, since adding the 8th prime requires 19 times as many hashes to be checked; the 9th prime requires 23 times as many, and so on.  There is another way, though.

Prime origins are required to be in the form O = H * N where O is the origin, H is the hash, and N is any integer; H is selected to be divisible by p#7 (the primorial shown above).  If we extend this to O = H * N * P₂ where P₂ is 19 * 23 * 29 * ... * 51--a product of primes starting after the last prime used in the existing search--then the checked origin is still valid (an integer times an integer is still an integer).  This grants the benefits of searching with a higher degree primorial while not requiring a longer search for a working hash.  

Nothing is free, though, as this method inflates the size of the primes to be checked.  If the fast modular exponentiation is implemented through the same method as is used on the Fermat Primality Test Wikipedia page then the algorithmic efficiency is O(log²(n) * log(log(n)) * log(log(log(n))) ).  There should be some sweet spot of how large of a primorial to use where the increased frequency of primes more than offsets the extra time required for the fast modular exponentiation.  It's possible that the sweet spot is 0 extra primes, but I think it's worth looking into.

Well, sir, you've managed to impress me. I am a biologist...math is one fish two fish, red fish blue fish.

[ReCat]

Second block I managed to mine with HP4. Seivesize 2M. I feel like getting adventurous and going to 4M...

[atomium]

you should upgrade to hp5, you got some awesome primespersec ive reached max of around 2500