blastbob


July 18, 2013, 10:38:18 PM 

I managed to get 70 Orphans in 3 hours on a small cluster.. Hard competition Using HP5

Psst.. Got Ether?






Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.


yourofl10


July 18, 2013, 10:44:39 PM 

I managed to get 70 Orphans in 3 hours on a small cluster.. Hard competition Using HP5 Where's your cloud cluster?




gateway


July 18, 2013, 10:46:18 PM 

hp5 released!This version adds a fast 32bit 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/primecoinhpBut please download the source code from SourceForge if you can. aaaand compiled and running Can anyone make a windows build please?




ivanlabrie


July 18, 2013, 10:48:53 PM 

hp5 released!This version adds a fast 32bit 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/primecoinhpBut 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


July 18, 2013, 11:01:49 PM 

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


July 18, 2013, 11:11:04 PM 

stopping the client on my ubuntu 12.x box spit this error out
fyi
gateway@a:~/work/primecoinhp/src$ ./primecoind stop Primecoin server stopping gateway@a:~/work/primecoinhp/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
Legendary
Offline
Activity: 1568


July 18, 2013, 11:12:34 PM 

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

Admitted Practicing Lawyer::BTC/Crypto Specialist. B.Engineering/B.Laws



Koooooj


July 18, 2013, 11:51:10 PM 

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 codeoptimization 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 ^{256} 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 quintillionimpractically 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 _{2} where P _{2} is 19 * 23 * 29 * ... * 51a product of primes starting after the last prime used in the existing searchthen 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 ^{2}(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


July 19, 2013, 12:47:36 AM 

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




forsetifox


July 19, 2013, 12:50:35 AM 

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


July 19, 2013, 12:51:35 AM 

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.

BTC: 1A1Mwjfw2mTko4N2UuVQ3RK4hXJunsPA3j XMP: AcT3PK4wofjCMt6irN4HXENUqPvoBJRWk3



blastbob


July 19, 2013, 12:51:51 AM 

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.

Psst.. Got Ether?



superfluouso


July 19, 2013, 12:57:52 AM 

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


July 19, 2013, 12:58:13 AM 

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




gateway


July 19, 2013, 01:53:29 AM 

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 510 min of launching.. need to find hp4 which worked fine..




dudeguy


July 19, 2013, 02:27:11 AM 

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 codeoptimization 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 ^{256} 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 quintillionimpractically 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 _{2} where P _{2} is 19 * 23 * 29 * ... * 51a product of primes starting after the last prime used in the existing searchthen 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 ^{2}(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!




glassuser
Donator
Sr. Member
Offline
Activity: 378
CoFounder and CEO of Coingig.com


July 19, 2013, 02:29:44 AM 

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


July 19, 2013, 02:41:27 AM 

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.

Whiskey Fund: (BTC) 1whiSKeYMRevsJMAQwU8NY1YhvPPMjTbM  (Ψ) ALcoHoLsKUfdmGfHVXEShtqrEkasihVyqW  (CGB) 5WHiSkEY8ocPHdeczVfpaGfquJK3j3Lqis



AstroKev
Newbie
Offline
Activity: 22


July 19, 2013, 03:14:47 AM 

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.

martingale gambler bot: http://goo.gl/b4XsJ



RandyFolds


July 19, 2013, 03:15:29 AM 

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 codeoptimization 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 ^{256} 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 quintillionimpractically 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 _{2} where P _{2} is 19 * 23 * 29 * ... * 51a product of primes starting after the last prime used in the existing searchthen 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 ^{2}(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.




