Quote from: AgentME on July 12, 2013, 11:36:11 PM

Quote from: Chemisist on July 12, 2013, 10:35:25 PM

Alright, so just updated my version (currently on github) such that each thread an independent evolving weave timing parameter. To compare to mine with Sunny's most recent update, I used the testnet where my version found 30 confirmed blocks in 10 minutes while the original code found 16 confirmed blocks. I feel that this is a legitimate comparison because there were no other nodes on the test net currently mining (I know this because my client found every continuous block in both cases). This comparison was performed with a t61p IBM laptop with a T9300 Core 2 Duo processor. The current difficulty on the testnet is 5.4426.

Why make it a weave timing parameter and not just a weave count parameter? I think that would be a better metric, as a change in CPU load means the timing parameter's results will change a lot.

Quote from: Chemisist on July 12, 2013, 10:43:08 PM

Quote from: gateway on July 12, 2013, 10:38:54 PM

some of us on #eligius-prime were able with lukes help and others to get it running.. now im just waiting to see if i can actually get a block..

[image]

Can you share your source code? Did you modify Sunny's algorithm at all?

I think the biggest change in Luke's miner is that it moves the bnTwoInverse calculation out of Weave() and just pre-calculates it for all of the primes in GeneratePrimeTable(). I didn't get much more performance out of porting that change though to primecoin but I didn't check too hard.

Thanks for the update on Luke's code.

The rationale for the weave timing parameter instead of the weave count parameter is because the weave timing parameter requires only a call to "GetTimeMicros()" whereas determining the weave count parameter is far more intensive to calculate. To calculate it requires looping through all three arrays to find the values that are still false:

from prime.h:

Code:

unsigned int GetCandidateCount()
   {
   unsigned int nCandidates = 0;
   for (unsigned int nMultiplier = 0; nMultiplier < nSieveSize; nMultiplier++)
   {
   if (!vfCompositeCunningham1[nMultiplier] ||
   !vfCompositeCunningham2[nMultiplier] ||
   !vfCompositeBiTwin[nMultiplier])
   nCandidates++;
   }
   return nCandidates;
   }

the vfComposite arrays are all start out as "0" and when a value is found that is not a prime compatible with Sunny's algorithm, that value gets set to 1. All vfComposite arrays are nMaxSieveSize in length:

Code:

static const unsigned int nMaxSieveSize = 1000000u;

So to calculate a weave count parameter requires 3 million boolean tests, plus the costs of a loop plus the increment operator for each time the if statement returns true.