eule


July 09, 2013, 01:26:16 PM 

He did: Has anybody else tried messing with the nMaxSieveSize variable? By chopping a zero off of it, I seemed to be able to get almost a 5x increase in pps. I know that reducing the sieve size would effectively reduce the amount of numbers checked for each run of the sieve and then reduce the likelyhood of finding a block, but is pps more important than search size?






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



nmersulypnem


July 09, 2013, 01:30:41 PM 

I thought difficulty will rise a lot when GPU miners appear?
The prime number searching range for Primecoin is roughly 2^100 ~ 2^2000 ( 100 digits ~ 2000 digits ). For the sake of simplicity, let's assume the primes are about 2^100. According to the Prime number theorem, the prime number distribution of this range is about 1 prime number in 230 integers. When difficulty grows from 7 to 8, it means the miner needs to find a prime chain of length 8 instead of 7, making the likelihood to 1/230 of before. In other word, it takes 230 times longer to find a 8chain than a 7chain if we assume the mining power remain the same. It would take 230*230*230 = 12167000 times longer to find a 10chain, that's 10 million times more difficult. Now let's take the GPU and other possible device into account. The GPU is very efficient of calculating hash, but in the specific case of primecoin, it doesn't seem have the same kind of advantage. Unless there are some specially designed hardware for prime searching, the mining speed at most will be less than 1000x faster. So it is quite clear that even with 10000x more miners equipped with monster machines, it is still not even close to reach difficulty 10. Where do you see that range in the code? I don't see it...




mustyoshi


July 09, 2013, 01:34:08 PM 

Left my somewhat optimized version running over night and came back to 3 additional blocks mined. Getting roughly ~60 pps with 500K sieve size and basic optimization flags. Running on a single thread of a stock i3 2120.
Dude. Post it. Keeping optimized miners secret is a bad move for your rep and the coin. Don't make me get my own optimized one to post. Other than the sieve size change. I also opted to pass the blockheader hash through the functions, instead of making calls to block>GetHeaderHash() every time. I'm not sure what kind of improvements that actually made since I also changed the sieve size when I first did it. But it stops me from running double SHA256 like 3 times more than I used to.




maka
Jr. Member
Offline
Activity: 54
Merit: 0


July 09, 2013, 01:39:44 PM 

I thought difficulty will rise a lot when GPU miners appear?
The prime number searching range for Primecoin is roughly 2^100 ~ 2^2000 ( 100 digits ~ 2000 digits ). For the sake of simplicity, let's assume the primes are about 2^100. According to the Prime number theorem, the prime number distribution of this range is about 1 prime number in 230 integers. When difficulty grows from 7 to 8, it means the miner needs to find a prime chain of length 8 instead of 7, making the likelihood to 1/230 of before. In other word, it takes 230 times longer to find a 8chain than a 7chain if we assume the mining power remain the same. It would take 230*230*230 = 12167000 times longer to find a 10chain, that's 10 million times more difficult. Now let's take the GPU and other possible device into account. The GPU is very efficient of calculating hash, but in the specific case of primecoin, it doesn't seem have the same kind of advantage. Unless there are some specially designed hardware for prime searching, the mining speed at most will be less than 1000x faster. So it is quite clear that even with 10000x more miners equipped with monster machines, it is still not even close to reach difficulty 10. Where do you see that range in the code? I don't see it... <prime.h> static const CBigNum bnPrimeMax = (bnOne << 2000)  1; static const CBigNum bnPrimeMin = (bnOne << 255);




eule


July 09, 2013, 01:44:23 PM 

nMaxSieveSize = 1000000u ~130  230 pps nMaxSieveSize = 100000u ~230  400 pps nMaxSieveSize = 10000u ~350  800 pps Running the second one now, no idea if this will make me mine more blocks or none. Also not sure about the other thing you mentioned, goes above my head.




nmersulypnem


July 09, 2013, 01:46:08 PM 

I thought difficulty will rise a lot when GPU miners appear?
The prime number searching range for Primecoin is roughly 2^100 ~ 2^2000 ( 100 digits ~ 2000 digits ). For the sake of simplicity, let's assume the primes are about 2^100. According to the Prime number theorem, the prime number distribution of this range is about 1 prime number in 230 integers. When difficulty grows from 7 to 8, it means the miner needs to find a prime chain of length 8 instead of 7, making the likelihood to 1/230 of before. In other word, it takes 230 times longer to find a 8chain than a 7chain if we assume the mining power remain the same. It would take 230*230*230 = 12167000 times longer to find a 10chain, that's 10 million times more difficult. Now let's take the GPU and other possible device into account. The GPU is very efficient of calculating hash, but in the specific case of primecoin, it doesn't seem have the same kind of advantage. Unless there are some specially designed hardware for prime searching, the mining speed at most will be less than 1000x faster. So it is quite clear that even with 10000x more miners equipped with monster machines, it is still not even close to reach difficulty 10. Where do you see that range in the code? I don't see it... <prime.h> static const CBigNum bnPrimeMax = (bnOne << 2000)  1; static const CBigNum bnPrimeMin = (bnOne << 255); I think an FPGA would be perfect for this...




mustyoshi


July 09, 2013, 01:52:14 PM 

nMaxSieveSize = 1000000u ~130  230 pps nMaxSieveSize = 100000u ~230  400 pps nMaxSieveSize = 10000u ~ 350  800 pps Running the second one now, no idea if this will make me mine more blocks or none. Also not sure about the other thing you mentioned, goes above my head. I'm not sure that reducing the sieve size is the best optimization, since by reducing it you also reduce the amount of potential numbers you are testing for the PoW... Who knows what that actually does to the potential of finding a correct PoW though.




oroqen


July 09, 2013, 01:57:06 PM 

nMaxSieveSize = 1000000u ~130  230 pps nMaxSieveSize = 100000u ~230  400 pps nMaxSieveSize = 10000u ~ 350  800 pps Running the second one now, no idea if this will make me mine more blocks or none. Also not sure about the other thing you mentioned, goes above my head. I'm not sure that reducing the sieve size is the best optimization, since by reducing it you also reduce the amount of potential numbers you are testing for the PoW... Who knows what that actually does to the potential of finding a correct PoW though. Running different Sieve values per thread rather than the current all threads same Sieve, could spread out that risk, even if it's just 1 out of 4 running at 10k and the other 3 at 1M




mustyoshi


July 09, 2013, 01:59:12 PM 

nMaxSieveSize = 1000000u ~130  230 pps nMaxSieveSize = 100000u ~230  400 pps nMaxSieveSize = 10000u ~ 350  800 pps Running the second one now, no idea if this will make me mine more blocks or none. Also not sure about the other thing you mentioned, goes above my head. I'm not sure that reducing the sieve size is the best optimization, since by reducing it you also reduce the amount of potential numbers you are testing for the PoW... Who knows what that actually does to the potential of finding a correct PoW though. Running different Sieve values per thread rather than the current all threads same Sieve, could spread out that risk, even if it's just 1 out of 4 running at 10k and the other 3 at 1M There's an idea. Then run that setup for a day and figure out proportionally which sieve size resulted in the most correct PoWs.




eule


July 09, 2013, 02:01:42 PM 

Who knows what that actually does to the potential of finding a correct PoW though.
Indeed, might go horribly wrong. But I didn't mine anything since 1800 blocks on that machine, nothing to lose. Running different Sieve values per thread rather than the current all threads same Sieve, could spread out that risk, even if it's just 1 out of 4 running at 10k and the other 3 at 1M
Hmm, is it possible to run multiple instances of primecoind? Or how to assign different sieves to different threads, VMs?




illpoet


July 09, 2013, 02:03:35 PM 

WTS Primecoin asic. 20,000 primespersec for just 1 watt of electricity. 10,000 btc. will ship sometime soon, i promise.
wait, too soon?

Tym's Get Rich Slow scheme: plse send .00001 to btc: 1DKRaNUnMQkeby6Dk1d8e6fRczSrTEhd8p ltc: LV4Udu7x9aLs28MoMCzsvVGKJbSmrHESnt thank you.



mpr20rt


July 09, 2013, 02:05:10 PM 

Left my somewhat optimized version running over night and came back to 3 additional blocks mined. Getting roughly ~60 pps with 500K sieve size and basic optimization flags. Running on a single thread of a stock i3 2120.
Dude. Post it. Keeping optimized miners secret is a bad move for your rep and the coin. Don't make me get my own optimized one to post. Other than the sieve size change. I also opted to pass the blockheader hash through the functions, instead of making calls to block>GetHeaderHash() every time. I'm not sure what kind of improvements that actually made since I also changed the sieve size when I first did it. But it stops me from running double SHA256 like 3 times more than I used to. could you please post the codelines you've changed? cheers!

I'd like to thank eduffield and the other developers for this critically important evolution in virtual currency. DarkCoin is what bitcoin should have been. Some might call it "Bitcoin 2.0" but would do better by saying: "DarkCoin is digital cash."  Child Harold  February 28, 2014 https://bitcointalk.org/index.php?topic=421615.msg5424980#msg5424980



E.Sam


July 09, 2013, 02:08:33 PM 

My first solo mined coin
Was starring at screen, wondering if anything would actually happen... and 18.77 XPM just appeared :]
Took me 6:30 hours on a iMac 3.4GH i7
Wow, that's a long time to be staring at the screen but whatever helps... tb Was worth the excitement :]




bidji29


July 09, 2013, 02:11:21 PM 

Any hope of a gpu version? At least with my current (still incomplete) comprehension of the algorithm, it requires a bignum library. With this in mind, I don't plan to do a GPU port on my spare time. Maybe later, after CPU is working, if someone is willing to sponsor the development time. LukeJr, do you have any hints for people getting started on where to look or what to look for? Are you running Linux? Well, the most obvious one was hashing the block header once per nonce instead of 13x... I think the rest of my optimizations required actually comprehending the code Any idea how to "hashing the block header once per nonce instead of 13x..."




paulthetafy


July 09, 2013, 02:12:22 PM 

Is it possible to have multiple primecoind instances on different machines use a single wallet? I thought that this could be achieved by using connect=<ip of server> for all of the slave primecoind instances, is that right?




ReCat


July 09, 2013, 02:12:39 PM 

WTS Primecoin asic. 20,000 primespersec for just 1 watt of electricity. 10,000 btc. will ship sometime soon, i promise.
wait, too soon?
You forgot to say that you're BFL.

BTC: 1recatirpHBjR9sxgabB3RDtM6TgntYUW Hold onto what you love with all your might, Because you can never know when  Oh. What you love is now gone.



nmersulypnem


July 09, 2013, 02:13:38 PM 

nMaxSieveSize = 1000000u ~130  230 pps nMaxSieveSize = 100000u ~230  400 pps nMaxSieveSize = 10000u ~ 350  800 pps Running the second one now, no idea if this will make me mine more blocks or none. Also not sure about the other thing you mentioned, goes above my head. I'm not sure that reducing the sieve size is the best optimization, since by reducing it you also reduce the amount of potential numbers you are testing for the PoW... Who knows what that actually does to the potential of finding a correct PoW though. Is there only one correct PoW? How does the program choose where to start looking in the range? Is it random?





mustyoshi


July 09, 2013, 02:15:19 PM 

could you please post the codelines you've changed?
cheers!
My lines are gonna be off since I also removed the printf statements that were inside the loops. The debug file isn't important to me anymore so eh. But here ya go, no changes to the algorithm itself yet, my knowledge of math isn't in this area. main.cpp 4610: uint256 phash = pblock>GetHeaderHash();
4611  4614: while ((phash < hashBlockHeaderLimit  CBigNum(phash) % bnHashFactor != 0) && pblock>nNonce < 0xffff0000){ pblock>nNonce++; phash = pblock>GetHeaderHash(); }
4644: CBigNum bnMultiplierMin = bnPrimeMin * bnHashFactor / CBigNum(phash) + 1; 4655: if (MineProbablePrimeChain(*pblock, bnFixedMultiplier, fNewBlock, nTriedMultiplier, nProbableChainLength, nTests, nPrimesHit,phash))
prime.h 10: static const unsigned int nMaxSieveSize = 500000u; 60: bool MineProbablePrimeChain(CBlock& block, CBigNum& bnFixedMultiplier, bool& fNewBlock, unsigned int& nTriedMultiplier, unsigned int& nProbableChainLength, unsigned int& nTests, unsigned int& nPrimesHit,uint256& headerhash);
prime.cpp 342: bool MineProbablePrimeChain(CBlock& block, CBigNum& bnFixedMultiplier, bool& fNewBlock, unsigned int& nTriedMultiplier, unsigned int& nProbableChainLength, unsigned int& nTests, unsigned int& nPrimesHit,uint256& headerhash)
360: psieve.reset(new CSieveOfEratosthenes(nMaxSieveSize, block.nBits, headerhash, bnFixedMultiplier)); 380: bnChainOrigin = CBigNum(headerhash) * bnFixedMultiplier * nTriedMultiplier;




grc
Jr. Member
Offline
Activity: 40
Merit: 0


July 09, 2013, 02:27:51 PM 

could you please post the codelines you've changed?
cheers!
My lines are gonna be off since I also removed the printf statements that were inside the loops. The debug file isn't important to me anymore so eh. But here ya go, no changes to the algorithm itself yet, my knowledge of math isn't in this area. ... If you're changing the max sieve size, I think you can also change the vector sizes on lines 102104.




