Bitcoin Forum
October 23, 2017, 02:18:49 PM *
News: Latest stable version of Bitcoin Core: 0.15.0.1  [Torrent]. (New!)
 
   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 392651 times)
blastbob
Hero Member
*****
Offline Offline

Activity: 588



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

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

Using HP5

Psst.. Got Ether?
1508768329
Hero Member
*
Offline Offline

Posts: 1508768329

View Profile Personal Message (Offline)

Ignore
1508768329
Reply with quote  #2

1508768329
Report to moderator
1508768329
Hero Member
*
Offline Offline

Posts: 1508768329

View Profile Personal Message (Offline)

Ignore
1508768329
Reply with quote  #2

1508768329
Report to moderator
1508768329
Hero Member
*
Offline Offline

Posts: 1508768329

View Profile Personal Message (Offline)

Ignore
1508768329
Reply with quote  #2

1508768329
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1508768329
Hero Member
*
Offline Offline

Posts: 1508768329

View Profile Personal Message (Offline)

Ignore
1508768329
Reply with quote  #2

1508768329
Report to moderator
1508768329
Hero Member
*
Offline Offline

Posts: 1508768329

View Profile Personal Message (Offline)

Ignore
1508768329
Reply with quote  #2

1508768329
Report to moderator
1508768329
Hero Member
*
Offline Offline

Posts: 1508768329

View Profile Personal Message (Offline)

Ignore
1508768329
Reply with quote  #2

1508768329
Report to moderator
yourofl10
Full Member
***
Offline Offline

Activity: 168


View Profile
July 18, 2013, 10:44:39 PM
 #782

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

Using HP5

Where's your cloud cluster?

gateway
Hero Member
*****
Offline Offline

Activity: 537


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

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

Activity: 812



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

-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: 537


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

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: 537


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

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: 1624


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

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

Activity: 75



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

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: 537


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

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

forsetifox
Sr. Member
****
Offline Offline

Activity: 266



View Profile
July 19, 2013, 12:50:35 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.
Plazma
Full Member
***
Offline Offline

Activity: 224



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

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: 588



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

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


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

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: 513



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

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

gateway
Hero Member
*****
Offline Offline

Activity: 537


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

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: 84



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

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


Co-Founder and CEO of Coingig.com


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

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: 243


My spoon is too big!


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

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 Offline

Activity: 22


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

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.

martingale gambler bot: http://goo.gl/b4XsJ
RandyFolds
Sr. Member
****
Offline Offline

Activity: 448



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

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.
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!