Bitcoin Forum
October 22, 2018, 03:00:43 AM *
News: Make sure you are not using versions of Bitcoin Core other than 0.17.0 [Torrent], 0.16.3, 0.15.2, or 0.14.3. More info.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 [40] 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 ... 133 »
  Print  
Author Topic: [XPM] [ANN] Primecoin High Performance | HP14 released!  (Read 396549 times)
gateway
Hero Member
*****
Offline Offline

Activity: 551
Merit: 500


View Profile
July 18, 2013, 10:46:18 PM
 #781

-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?
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1540177243
Hero Member
*
Offline Offline

Posts: 1540177243

View Profile Personal Message (Offline)

Ignore
1540177243
Reply with quote  #2

1540177243
Report to moderator
1540177243
Hero Member
*
Offline Offline

Posts: 1540177243

View Profile Personal Message (Offline)

Ignore
1540177243
Reply with quote  #2

1540177243
Report to moderator
1540177243
Hero Member
*
Offline Offline

Posts: 1540177243

View Profile Personal Message (Offline)

Ignore
1540177243
Reply with quote  #2

1540177243
Report to moderator
ivanlabrie
Hero Member
*****
Offline Offline

Activity: 812
Merit: 1000



View Profile
July 18, 2013, 10:48:53 PM
 #782

-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
Hero Member
*****
Offline Offline

Activity: 551
Merit: 500


View Profile
July 18, 2013, 11:01:49 PM
 #783

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
Hero Member
*****
Offline Offline

Activity: 551
Merit: 500


View Profile
July 18, 2013, 11:11:04 PM
 #784

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
Legendary
*
Offline Offline

Activity: 1876
Merit: 1002


View Profile WWW
July 18, 2013, 11:12:34 PM
 #785

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

https://www.binance.com/?ref=10062065
Koooooj
Member
**
Offline Offline

Activity: 75
Merit: 10



View Profile
July 18, 2013, 11:51:10 PM
 #786

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.
gateway
Hero Member
*****
Offline Offline

Activity: 551
Merit: 500


View Profile
July 19, 2013, 12:47:36 AM
 #787

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

forsetifox
Sr. Member
****
Offline Offline

Activity: 266
Merit: 250



View Profile
July 19, 2013, 12:50:35 AM
 #788

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
Full Member
***
Offline Offline

Activity: 224
Merit: 100



View Profile
July 19, 2013, 12:51:35 AM
 #789

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
Hero Member
*****
Offline Offline

Activity: 602
Merit: 500



View Profile
July 19, 2013, 12:51:51 AM
 #790

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
Full Member
***
Offline Offline

Activity: 202
Merit: 100


View Profile
July 19, 2013, 12:57:52 AM
 #791

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
Hero Member
*****
Offline Offline

Activity: 531
Merit: 500



View Profile
July 19, 2013, 12:58:13 AM
 #792

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

gateway
Hero Member
*****
Offline Offline

Activity: 551
Merit: 500


View Profile
July 19, 2013, 01:53:29 AM
 #793

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
Member
**
Offline Offline

Activity: 182
Merit: 10



View Profile
July 19, 2013, 02:27:11 AM
 #794

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.

This!
glassuser
Donator
Sr. Member
*
Offline Offline

Activity: 378
Merit: 250


Co-Founder and CEO of Coingig.com


View Profile WWW
July 19, 2013, 02:29:44 AM
 #795

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
Sr. Member
****
Offline Offline

Activity: 246
Merit: 250


My spoon is too big!


View Profile
July 19, 2013, 02:41:27 AM
 #796

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
AstroKev
Newbie
*
Offline Offline

Activity: 23
Merit: 0


View Profile
July 19, 2013, 03:14:47 AM
 #797

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


Quote
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
Sr. Member
****
Offline Offline

Activity: 448
Merit: 250



View Profile
July 19, 2013, 03:15:29 AM
 #798

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.

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

Activity: 406
Merit: 250



View Profile WWW
July 19, 2013, 03:18:14 AM
 #799



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

BTC: 1recatirpHBjR9sxgabB3RDtM6TgntYUW
Hold onto what you love with all your might, Because you can never know when - Oh. What you love is now gone.
glassuser
Donator
Sr. Member
*
Offline Offline

Activity: 378
Merit: 250


Co-Founder and CEO of Coingig.com


View Profile WWW
July 19, 2013, 03:19:46 AM
 #800

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

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 [40] 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 ... 133 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!