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.
Topic: [XPM] [ANN] Primecoin High Performance | HP14 released! - page 93. (Read 397645 times)
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.
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.
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.
64bit hp5 version crashes after a bit on my windows 7 box.. 64 bit.. with this..
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 2256 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 * P2 where P2 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(log2(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.
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 2256 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 * P2 where P2 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(log2(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.
what happened went from 14K pps to 6K pps accross all machines, did some sort of botnet come on? bug in hp5?
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.
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.
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.
It compiles fine but when running after a few sec it quits
user$ Assertion failed: (pfork != NULL), function SetBestChain, file main.cpp, line 1722.
-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.
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.
-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.
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?
I managed to get 70 Orphans in 3 hours on a small cluster.. Hard competition 
Using HP5
Using HP5
it's been cleared that blocks are in the big player hands and they haven't dumped them on exchanges yet.
Maybe yes, but wich cryptocurrency haven't big players??
Mined for a few days with over 8,000 pps fucking nothing. I am using the HP client with an overclocked watercooled 3930k @ 4.6GHz. 
Just one machine, for just a few days?
Gambling, basically. Variance alone probably means you would need to mine for several months or several machines at an unchanging difficulty (which latter doesn't seem likely to happen) just to obtain a small amount of data that still would likely leave a lot of doubt as to whether you just got lucky or unlucky and still haven't really got a decent estimate of the statistical chance of finding a block in a specified amount of time.
Try a thousand such machines for a week or two maybe and see how many per thousand happen to get a block...
But of course please do stop mining, it benefits everyone else and maybe you too.
-MarkM-
Tee-Hee!
Mined for a few days with over 8,000 pps fucking nothing. I am using the HP client with an overclocked watercooled 3930k @ 4.6GHz.
it's been cleared that blocks are in the big player hands and they haven't dumped them on exchanges yet.
Block Found With Release 5!!! YEAH 
Code:
CTxMemPool::accept() : accepted d9988a7bde33f356b95ee958517db87a88cc75aff1994a3de370018aac3be418 (poolsz 2)
Added 1 addresses from 192.241.213.177: 624 tried, 11539 new
2013-07-18 20:48:05 primemeter 8786081 prime/h 67110064 test/h 300 5-chains/h
Probable prime chain found for block=8c681b622935423bc52f4701891f0894bf142f9a6b590fd884ac5466c5eea811!!
Target: 08.fa1ece
Length: (05.25c080 04.6a3c73 09.6a3c73)
PrimecoinMiner:
proof-of-work found
target: 08.fa1ece
multiplier: 93a34344c754b91bcda7211d1d9
CBlock(hash=8c681b622935423bc52f4701891f0894bf142f9a6b590fd884ac5466c5eea811, hashBlockHeader=98d1bd489103fc36f5916765a039e25a58d820661afd896a56b495c615d7b6d8, ver=2, hashPrevBlock=58f8217c76e534de17b1b59af60992caf159cb69accce6d10ce58f2a2a2769e1, hashMerkleRoot=01fd957807a4ee0f550aaede7840686f0a3a758748d0e73913cac26d309bbb46, nTime=1374180509, nBits=08fa1ece, nNonce=172, vtx=3)
CTransaction(hash=cafd4b67d146d8ad14304811146ab4feb559148f0d3fdd7ce1597bc4df77416d, ver=1, vin.size=1, vout.size=1, nLockTime=0)
CTxIn(COutPoint(0000000000000000000000000000000000000000000000000000000000000000, 4294967295), coinbase 03cef40002040400062f503253482f)
CTxOut(nValue=12.42000000, scriptPubKey=0291b06db1403ab091561f02922d92)
CTransaction(hash=3e5edfe74ea59baaf1a930ac2c21b52e8b2068ca3529583b50f39ad141d62e41, ver=1, vin.size=14, vout.size=2, nLockTime=0)
CTxIn(COutPoint(311e3c52c12dd3fe789901b8cea3a4f069cdd19ac66571d556446d98df24e013, 0), scriptSig=3044022019838a4b8ad5656c)
CTxIn(COutPoint(a85eebe141aeeafeb7e80e556f414fb82b62be2c581d846bcbb2e12b6116a840, 0), scriptSig=304602210089b7ec53a26bc4)
CTxIn(COutPoint(150380ee0e83d8260e7ae6990eb3630fccf3a994d0be6ac932d7b9c896888501, 0), scriptSig=3046022100ae1ad9c98e3095)
CTxIn(COutPoint(b245747b9ff6a61fff1f9e7b2bdb0ac5935b996b5fd56f651ab10bbf83cc2475, 0), scriptSig=30450220633b8f88661dcd91)
CTxIn(COutPoint(5ec6f305ac0e9f0d4288e5b2bfd211b1dfe429cf79a3e454216d0bdbe64a927e, 0), scriptSig=3045022100a477b250c01dc1)
CTxIn(COutPoint(32d83530d911075170274a2a5da756fe5cefe3c99100df03af18bd1e8f756d8a, 0), scriptSig=3046022100b3d181398d1561)
CTxIn(COutPoint(dc5e91482cb9dbdc74ddc150776ff5b4c571a829b03eb8ae4e39100d65faee92, 0), scriptSig=30450221009cbb984e38f25b)
CTxIn(COutPoint(b3a9a98a0f7cce9722c456dae7ab8add4e717f4b8700c4d206adbfea0238c9a7, 0), scriptSig=30440220258420085556ad5b)
CTxIn(COutPoint(af990e29989d6b561c3075319f66e58e37cad05d27835a7ee4ed172a490e68a9, 0), scriptSig=3045022100e8353eefcad13d)
CTxIn(COutPoint(dfc74fbcae2f630af941935bdea7a88df1503b1cb209d77416ad08ac178afec7, 0), scriptSig=3045022100d825c9e50d5d90)
CTxIn(COutPoint(f79ccbb1165abd6d02a7d1bd62950749a4e7f362cb0035a884bb8da0f705a9d6, 0), scriptSig=3045022100a33f9a5ad614e0)
CTxIn(COutPoint(2d13083db78cfa103c374e9d026ccb9f1c289c067a103df636c6e5cd88832e05, 0), scriptSig=30450221008031934a373a11)
CTxIn(COutPoint(19ec15f6d80f3500df1af679a1d3d136f0d56c1e398648b5bf30fe2e92ea384f, 0), scriptSig=3044022054370bd835ac5a19)
CTxIn(COutPoint(8a495edcf605925b0787d094926f16e42e35d3d43afeba88788ec51967ecb057, 0), scriptSig=3045022029af531a5f919f3b)
CTxOut(nValue=174.00000000, scriptPubKey=OP_DUP OP_HASH160 7ba534bee5e1)
CTxOut(nValue=0.06000000, scriptPubKey=OP_DUP OP_HASH160 c573f52bb550)
CTransaction(hash=d9988a7bde33f356b95ee958517db87a88cc75aff1994a3de370018aac3be418, ver=1, vin.size=4, vout.size=2, nLockTime=0)
CTxIn(COutPoint(54ae822dbec7eae8da62af1b1b964ba76ce682586e63ea867955fe143b21b44a, 0), scriptSig=3045022074255dc4b4cc1bec)
CTxIn(COutPoint(5446334d552df29cdd60598de962a3add8ca0b3f5fb3c055ac14cb5cf812f5a3, 0), scriptSig=3046022100dd8972371b1c91)
CTxIn(COutPoint(561fcaa93f0f027f24b857b2122bbb96719747b24f5775e588cfb3e48813faab, 0), scriptSig=3046022100d59b9ac25ffff5)
CTxIn(COutPoint(c6d30b6a1435b092f83746433aa8316e68fc04c117fa05745a401981e39f8c98, 0), scriptSig=304502205937aa9e49d7a15d)
CTxOut(nValue=48.00000000, scriptPubKey=OP_DUP OP_HASH160 7ba534bee5e1)
CTxOut(nValue=0.75000000, scriptPubKey=OP_DUP OP_HASH160 b4260f8efc18)
vMerkleTree: cafd4b67d146d8ad14304811146ab4feb559148f0d3fdd7ce1597bc4df77416d 3e5edfe74ea59baaf1a930ac2c21b52e8b2068ca3529583b50f39ad141d62e41 d9988a7bde33f356b95ee958517db87a88cc75aff1994a3de370018aac3be418 1dc6f59c3f9e050577c0cd93e3ced2e8777cae054cabd4337c5ccabd35158298 a8032578e443ae454cdb65c51a5325f9d7bb3fac05403fd516f53131c4a95428 01fd957807a4ee0f550aaede7840686f0a3a758748d0e73913cac26d309bbb46
generated 12.42
keypool keep 3
AddToWallet cafd4b67d146d8ad14304811146ab4feb559148f0d3fdd7ce1597bc4df77416d new
NotifyTransactionChanged cafd4b67d146d8ad14304811146ab4feb559148f0d3fdd7ce1597bc4df77416d status=0
updateWallet cafd4b67d146d8ad14304811146ab4feb559148f0d3fdd7ce1597bc4df77416d 0
inWallet=1 inModel=0 Index=2-2 showTransaction=0 derivedStatus=0
Is it normal to get less pps with hp5 ?
Edit : nvm I get 6-7% more pps
I'm not sure it's worth solo mining anymore though, nothing for almost 48h with i7 3770k @ 4400
Edit : nvm I get 6-7% more pps
I'm not sure it's worth solo mining anymore though, nothing for almost 48h with i7 3770k @ 4400
Do we need to adjust the sievesize in accordance to upcoming increase in difficulty?
Huh. If this chart is correct, me and a friend are collectively mining 10% of all blocks in the past 24 hours. Kind of cool to be a big fish for once.
Sunny and Mikael are going to be seeing a huge donation from me if this goes well.
You're claiming you found 400 blocks in the last 24 hours? Sunny and Mikael are going to be seeing a huge donation from me if this goes well.
Jump to: