Topic: [XPM] [ANN] Primecoin High Performance | HP14 released! - page 91. (Read 397645 times)

That is indeed called pure luck.

Sorry i am new to all this ...
But there is one thing i dont get.
I tryed to run it with a primecoin.conf file and changed parameters like rpcuser ... rpcpassword ... gen=0 gen=1 and also with rpcport=9910 rpcallowip=127.0.0.1 with server=1 and daemon=1.
I did not receive any block in earlier stages ... difficulty was past 8 to this stage ...
as i deleted the conf file and run the wallet without it i received two blocks in two hours ...
How can that be ... Luck ? I was using hp3 ...
So my question is is the conf file needed or not ??

Thx

mikael, knowing your work I'll take your word for it, do you agree that 1) is a change for the better and will not negatively effect block finding?

You seem to be testing two changes at the same time. The first change will definitely affect performance while the second change shouldn't as people have already pointed out. It's likely you're only seeing the effects of the first change you did.

Each of us has collected over 2k XPM in the past day. 200 blocks*

aws cc2.8xlarge,
primecoin-0.1.1-hp5 two changes:

1) prime.cpp
const unsigned int nPrimes = (uint64)nTotalPrimes * 8 / 100;  // down from 10

2) main.cpp
static const unsigned int nPrimorialHashFactor = 9; // up from 7

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.

No this is not what primorial means.  

primorial(1) = 2
primorial(2) = 2 * 3
primorial(3) = 2 * 3 * 5
and so forth.
primorial(7) = 2 * 3 * 5 * 7 * 11 * 13 * 17 = 510510
primorial(9) = 2 * 3 * 5 * 7 * 11 * 13 * 17 * 19 * 23 = 223092870



Notice the list of divisors this produces when using p#9 * some random price
> bc
print 223092870 * 498497689
111211280127377430

http://www.wolframalpha.com/input/?i=factor+%28111211280127377430%29



Honestly I can't say I really understand what the code is doing here, but based on some the comments from Kooooooj and running through gprof, Weave is sucking up all the time -- so I was trying to push some of the work out of there and into the caller function.  I am 100% speculating also that the increases in difficulty may make the primorial a little more important. But anyway, mostly just hacking.


oh well, off to bed.

Have you found any blocks with these changes? My very poor understanding of the algorithm suggests that changing the has factor will not work...

In one case, varying nonce and finding a block header hash that is divisible by a small
primorial number – the product of all primes smaller than a given prime p – can help
only slightly. It allows the prime miner to work on somewhat smaller primes, like maybe
a few digits shorter, for prime numbers of typically 100 digits, only a very small
advantage.

Did you test with other number aswell?

I could be wrong, but I'm not convinced this change will make any significant difference. The primorial of 7 is the same as that of 9, since 8 and 9 aren't primes.

2) main.cpp
static const unsigned int nPrimorialHashFactor = 9; // up from 7

Some more stats for people to have fun with:

aws cc2.8xlarge,
primecoin-0.1.1-hp5 native

2013-07-19 06:03:07 primemeter  79132085 prime/h 688566896 test/h      2040 5-chains/h
2013-07-19 06:04:07 primemeter  79653622 prime/h 698384521 test/h      2700 5-chains/h
2013-07-19 06:05:07 primemeter  79337338 prime/h 695558447 test/h      2040 5-chains/h
2013-07-19 06:06:07 primemeter  79792250 prime/h 695628406 test/h      1560 5-chains/h
2013-07-19 06:07:07 primemeter  80470419 prime/h 705139328 test/h      2280 5-chains/h
2013-07-19 06:08:07 primemeter  80764354 prime/h 704518758 test/h      1980 5-chains/h
2013-07-19 06:09:07 primemeter  76383887 prime/h 667428216 test/h      1500 5-chains/h


avg 5-chains/h ~~ 2000

------

aws cc2.8xlarge,
primecoin-0.1.1-hp5 two changes:

1) prime.cpp
const unsigned int nPrimes = (uint64)nTotalPrimes * 8 / 100;  // down from 10

2) main.cpp
static const unsigned int nPrimorialHashFactor = 9; // up from 7

2013-07-19 06:12:12 primemeter  52307908 prime/h 395403610 test/h      2640 5-chains/h
2013-07-19 06:13:12 primemeter  56580497 prime/h 440204443 test/h      2820 5-chains/h
2013-07-19 06:14:12 primemeter  56291842 prime/h 438057079 test/h      3000 5-chains/h
2013-07-19 06:15:12 primemeter  56267549 prime/h 437380981 test/h      2100 5-chains/h
2013-07-19 06:16:12 primemeter  56236005 prime/h 432883711 test/h      2580 5-chains/h
2013-07-19 06:17:12 primemeter  54281275 prime/h 412524505 test/h      2580 5-chains/h
2013-07-19 06:18:12 primemeter  54689509 prime/h 419307812 test/h      2220 5-chains/h

avg 5-chains/h ~~ 2500

Where do I go for the latest miner updates etc?