Topic: [XPM] [ANN] Primecoin Release - First Scientific Computing Cryptocurrency - page 139. (Read 688812 times)
July 10, 2013, 04:22:36 PM
malloc should be minimized by using a pool of reusable arrays, expand the pool as needed but never delete them or create them unessarily, this will be a huge improvement.
July 10, 2013, 04:11:13 PM
For the two for loop, i get that
i'm not sure of myself on this one
Code:
// Weave the sieve for the prime
unsigned int nChainLength = TargetGetLength(nBits);
for (; nBiTwinSeq < nChainLength; nBiTwinSeq++)
{
// Find the first number that's divisible by this prime
int nDelta = ((nBiTwinSeq % 2 == 0)? (-1) : 1);
unsigned int nSolvedMultiplier = ((bnFixedInverse * (p - nDelta)) % p).getuint();
if (nBiTwinSeq % 2 == 1)
bnFixedInverse *= bnTwoInverse; // for next number in chain
unsigned int nPrime = vPrimes[nPrimeSeq];
if (nBiTwinSeq < nChainLength)
for (unsigned int nVariableMultiplier = nSolvedMultiplier; nVariableMultiplier < nMaxSieveSize; nVariableMultiplier += nPrime)
vfCompositeBiTwin[nVariableMultiplier] = true;
if (((nBiTwinSeq & 1u) == 0))
for (unsigned int nVariableMultiplier = nSolvedMultiplier; nVariableMultiplier < nMaxSieveSize; nVariableMultiplier += nPrime)
vfCompositeCunningham1[nVariableMultiplier] = true;
else
for (unsigned int nVariableMultiplier = nSolvedMultiplier; nVariableMultiplier < nMaxSieveSize; nVariableMultiplier += nPrime)
vfCompositeCunningham2[nVariableMultiplier] = true;
}
for (; nBiTwinSeq < 2 * nChainLength; nBiTwinSeq++)
{
// Find the first number that's divisible by this prime
int nDelta = ((nBiTwinSeq % 2 == 0)? (-1) : 1);
unsigned int nSolvedMultiplier = ((bnFixedInverse * (p - nDelta)) % p).getuint();
if (nBiTwinSeq % 2 == 1)
bnFixedInverse *= bnTwoInverse; // for next number in chain
unsigned int nPrime = vPrimes[nPrimeSeq];
if (nBiTwinSeq < nChainLength)
for (unsigned int nVariableMultiplier = nSolvedMultiplier; nVariableMultiplier < nMaxSieveSize; nVariableMultiplier += nPrime)
vfCompositeBiTwin[nVariableMultiplier] = true;
if (((nBiTwinSeq & 1u) == 0))
for (unsigned int nVariableMultiplier = nSolvedMultiplier; nVariableMultiplier < nMaxSieveSize; nVariableMultiplier += nPrime)
vfCompositeCunningham1[nVariableMultiplier] = true;
else
for (unsigned int nVariableMultiplier = nSolvedMultiplier; nVariableMultiplier < nMaxSieveSize; nVariableMultiplier += nPrime)
vfCompositeCunningham2[nVariableMultiplier] = true;
}
i'm not sure of myself on this one
July 10, 2013, 04:08:27 PM
where's the most efficient code ?
8 cores in total 24 hours got nothing.
8 cores in total 24 hours got nothing.
July 10, 2013, 04:03:54 PM
Well it seems the little guys are out now. The big machines are up and running with the fixed code 
.
BTW seems like we have a 10 second gap between blocks now
.
My proposed p2pool client can't operate when the network speed is the same as the p2p chain speed is supposed to be.. BTW seems like we have a 10 second gap between blocks now
.Ahh that's disappointing. Too bad blocks are being found an entire 6 times faster than they're supoosed to be...
July 10, 2013, 04:00:44 PM
Well it seems the little guys are out now. The big machines are up and running with the fixed code .
BTW seems like we have a 10 second gap between blocks now.
My proposed p2pool client can't operate when the network speed is the same as the p2p chain speed is supposed to be. . BTW seems like we have a 10 second gap between blocks now
. July 10, 2013, 03:58:16 PM
Well it seems the little guys are out now. The big machines are up and running with the fixed code .
BTW seems like we have a 10 second gap between blocks now.
. BTW seems like we have a 10 second gap between blocks now
. 
July 10, 2013, 03:58:04 PM
I just had a transaction confirmed in under a minute.
The effective mining rate of the network is waaaaay faster than it should be.
The effective mining rate of the network is waaaaay faster than it should be.
The per-block difficulty adjustment seems to lag behind.
July 10, 2013, 03:52:51 PM
Thanks for sharing Mike270 
We are now onto the 4th day of mining (74 hours since launch)...
Some rough observations:
If you are running the original binary released by Sunny, then you have very little chance of finding a block in less than 15 seconds IMO
We are now onto the 4th day of mining (74 hours since launch)...
Some rough observations:
- Day 1 block spacing was in the range 40 - 110 seconds | difficulty 7 - 7.2
- Day 2 block spacing was in the range 10 - 40 seconds | difficulty 7.2 - 7.33
- Day 3 block spacing was in the range 15 - 25 seconds | difficulty 7.4 - 7.6
If you are running the original binary released by Sunny, then you have very little chance of finding a block in less than 15 seconds IMO
Yeah I'm watching all the blocks I'm not mining right now
July 10, 2013, 03:52:25 PM
I just had a transaction confirmed in under a minute.
The effective mining rate of the network is waaaaay faster than it should be.
The effective mining rate of the network is waaaaay faster than it should be.
July 10, 2013, 03:48:30 PM
Difficult to say, as Sunny King's change brings a huge boost to primes/sec measurement, and since we already know that this is not a real measurement....
I found three blocks in 1,5h whereas I only had 2 blocks in the 24h before that, but since we're talking luck this may well just be a statistical anomaly.
With all mentioned optimizations in place I now see
2013-07-10 19:54:30 primemeter 1229628 prime/h 9519403 test/h
2013-07-10 19:56:30 primemeter 1200380 prime/h 9385149 test/h
2013-07-10 19:58:31 primemeter 1059123 prime/h 8281702 test/h
2013-07-10 20:00:32 primemeter 1132707 prime/h 8806710 test/h
Whereas before I had
2013-07-09 16:01:06 primemeter 191133 prime/h 1230638 test/h
2013-07-09 16:03:07 primemeter 207187 prime/h 1333814 test/h
2013-07-09 16:05:07 primemeter 197670 prime/h 1302659 test/h
2013-07-09 16:07:08 primemeter 226844 prime/h 1538940 test/h
2013-07-09 16:08:09 primemeter 241089 prime/h 1653641 test/h
2013-07-09 16:10:09 primemeter 246644 prime/h 1574452 test/h
So if this helps, feel free to donate ;-)
XPM ALLbe86QswwTRvx1LTVnKaVXCz6mcA6YUR
BTC 135oF6hF9uUbzq9x1vTuaoqKPab2j513f2
I'm thinking the biggest improvements can be done by
a) optimizing the algorithm itself, possible according to TacoTime's post
b) minimizing malloc()s
and I guess there's still lots of potential.
If I had more time I'd try looking into using smaller sieves that fit into CPU cache but doing more sieves (so that the range sieved remains the same)
I found three blocks in 1,5h whereas I only had 2 blocks in the 24h before that, but since we're talking luck this may well just be a statistical anomaly.
With all mentioned optimizations in place I now see
2013-07-10 19:54:30 primemeter 1229628 prime/h 9519403 test/h
2013-07-10 19:56:30 primemeter 1200380 prime/h 9385149 test/h
2013-07-10 19:58:31 primemeter 1059123 prime/h 8281702 test/h
2013-07-10 20:00:32 primemeter 1132707 prime/h 8806710 test/h
Whereas before I had
2013-07-09 16:01:06 primemeter 191133 prime/h 1230638 test/h
2013-07-09 16:03:07 primemeter 207187 prime/h 1333814 test/h
2013-07-09 16:05:07 primemeter 197670 prime/h 1302659 test/h
2013-07-09 16:07:08 primemeter 226844 prime/h 1538940 test/h
2013-07-09 16:08:09 primemeter 241089 prime/h 1653641 test/h
2013-07-09 16:10:09 primemeter 246644 prime/h 1574452 test/h
So if this helps, feel free to donate ;-)
XPM ALLbe86QswwTRvx1LTVnKaVXCz6mcA6YUR
BTC 135oF6hF9uUbzq9x1vTuaoqKPab2j513f2
I'm thinking the biggest improvements can be done by
a) optimizing the algorithm itself, possible according to TacoTime's post
b) minimizing malloc()s
and I guess there's still lots of potential.
If I had more time I'd try looking into using smaller sieves that fit into CPU cache but doing more sieves (so that the range sieved remains the same)
nice, you building on windows or *nix?
building on Ubuntu. Should I get phenomenal results (ahem) I'll try to follow the instructions on how to set up a windows build environment for my windows machines.
Processor on that machine is an i7-920 at stock speeds, primecoind mining with 6 threads at nice 20 (the machine also has other stuff to do, like running bfgminer on my fpgas :-) )
July 10, 2013, 03:41:03 PM
Difficult to say, as Sunny King's change brings a huge boost to primes/sec measurement, and since we already know that this is not a real measurement....
I found three blocks in 1,5h whereas I only had 2 blocks in the 24h before that, but since we're talking luck this may well just be a statistical anomaly.
With all mentioned optimizations in place I now see
2013-07-10 19:54:30 primemeter 1229628 prime/h 9519403 test/h
2013-07-10 19:56:30 primemeter 1200380 prime/h 9385149 test/h
2013-07-10 19:58:31 primemeter 1059123 prime/h 8281702 test/h
2013-07-10 20:00:32 primemeter 1132707 prime/h 8806710 test/h
Whereas before I had
2013-07-09 16:01:06 primemeter 191133 prime/h 1230638 test/h
2013-07-09 16:03:07 primemeter 207187 prime/h 1333814 test/h
2013-07-09 16:05:07 primemeter 197670 prime/h 1302659 test/h
2013-07-09 16:07:08 primemeter 226844 prime/h 1538940 test/h
2013-07-09 16:08:09 primemeter 241089 prime/h 1653641 test/h
2013-07-09 16:10:09 primemeter 246644 prime/h 1574452 test/h
So if this helps, feel free to donate ;-)
XPM ALLbe86QswwTRvx1LTVnKaVXCz6mcA6YUR
BTC 135oF6hF9uUbzq9x1vTuaoqKPab2j513f2
I'm thinking the biggest improvements can be done by
a) optimizing the algorithm itself, possible according to TacoTime's post
b) minimizing malloc()s
and I guess there's still lots of potential.
If I had more time I'd try looking into using smaller sieves that fit into CPU cache but doing more sieves (so that the range sieved remains the same)
I found three blocks in 1,5h whereas I only had 2 blocks in the 24h before that, but since we're talking luck this may well just be a statistical anomaly.
With all mentioned optimizations in place I now see
2013-07-10 19:54:30 primemeter 1229628 prime/h 9519403 test/h
2013-07-10 19:56:30 primemeter 1200380 prime/h 9385149 test/h
2013-07-10 19:58:31 primemeter 1059123 prime/h 8281702 test/h
2013-07-10 20:00:32 primemeter 1132707 prime/h 8806710 test/h
Whereas before I had
2013-07-09 16:01:06 primemeter 191133 prime/h 1230638 test/h
2013-07-09 16:03:07 primemeter 207187 prime/h 1333814 test/h
2013-07-09 16:05:07 primemeter 197670 prime/h 1302659 test/h
2013-07-09 16:07:08 primemeter 226844 prime/h 1538940 test/h
2013-07-09 16:08:09 primemeter 241089 prime/h 1653641 test/h
2013-07-09 16:10:09 primemeter 246644 prime/h 1574452 test/h
So if this helps, feel free to donate ;-)
XPM ALLbe86QswwTRvx1LTVnKaVXCz6mcA6YUR
BTC 135oF6hF9uUbzq9x1vTuaoqKPab2j513f2
I'm thinking the biggest improvements can be done by
a) optimizing the algorithm itself, possible according to TacoTime's post
b) minimizing malloc()s
and I guess there's still lots of potential.
If I had more time I'd try looking into using smaller sieves that fit into CPU cache but doing more sieves (so that the range sieved remains the same)
nice, you building on windows or *nix?
July 10, 2013, 03:39:38 PM
I think it'd be ideal to use a 2D array with the three composite values stored sequentially in memory as single bits each
Probably should be a std::bitset datatype too
Probably should be a std::bitset datatype too
+1
When you guys get that figured out, pull requests would be much appreciated.
I was literally about to ask why there haven't been pull requests for this:) Much easier working off a common codebase than trying to implement scattered patches.
July 10, 2013, 03:39:33 PM
July 10, 2013, 03:39:23 PM
Sorry for my earlier error on Market cap. The newest exchange rates and coin total (168,186.31) yields a cap of around 68k which would be 15th just behind CNC. The hourly mining rate is equivalent to 6 BTC (assuming 1 minute blocks and 20.41 coins per block as the last few have been) which wold be $500 at current exchange rates, still 3rd over.
Going according to plan isn't it
Looking forward to XPM's debut on the network mining income pie chart
Are you doing the windows binary build?
July 10, 2013, 03:39:08 PM
I think it'd be ideal to use a 2D array with the three composite values stored sequentially in memory as single bits each
Probably should be a std::bitset datatype too
Hm, that would save memory but cost more in terms of computing (fiddling with all the bit shift operations).Probably should be a std::bitset datatype too
I think I'll first go for a plain int array and when I want to set a bit for the former arrays I can just do a |=,
and it will much simplify the ORing of all three arrays, so I'd guess it's only one malloc for the whole array and saving in computational efforts.
(Although I'm aware that those CBigNum probably much outweigh all these optimizations if one could save there)
July 10, 2013, 03:38:02 PM
Sorry for my earlier error on Market cap. The newest exchange rates and coin total (168,186.31) yields a cap of around 68k which would be 15th just behind CNC. The hourly mining rate is equivalent to 6 BTC (assuming 1 minute blocks and 20.41 coins per block as the last few have been) which wold be $500 at current exchange rates, still 3rd over.
Going according to plan isn't it
Looking forward to XPM's debut on the network mining income pie chart
July 10, 2013, 03:35:50 PM
I think it'd be ideal to use a 2D array with the three composite values stored sequentially in memory as single bits each
Probably should be a std::bitset datatype too
Probably should be a std::bitset datatype too
+1
When you guys get that figured out, pull requests would be much appreciated.
July 10, 2013, 03:34:32 PM
I think it'd be ideal to use a 2D array with the three composite values stored sequentially in memory as single bits each
Probably should be a std::bitset datatype too
Probably should be a std::bitset datatype too
+1
July 10, 2013, 03:31:54 PM
Thanks Mike!
I did some change but i don't understand some of them, like those three :
-did the headerhash mod outlined earlier
I did some change but i don't understand some of them, like those three :
-did the headerhash mod outlined earlier
https://bitcointalksearch.org/topic/m.2689981
(But I didn't change the MaxSieveSize)
-after creating vPrimes array in prime.cpp, store vPrimes.size() in a static variably and replace all calls to it with the variable
in prime.cpp:// Prime Table
std::vector
unsigned int vPrimessz; (<--- add this)
in GeneratePrimeTable(), add a last line:
vPrimessz=vPrimes.size();
Replace all other occurrences of vPrimes.size() with vPrimessz.
- in prime.cpp, CSieveOfEratosthenes::Weave() :
Split the for loop into two for loops, one going up to nChainLength, the other one going up to 2*nChainLength
Thus, you can safe the first first if+for clause in the first loop and leave away the if, and leave the if+for completely away in the second loop.
Split the for loop into two for loops, one going up to nChainLength, the other one going up to 2*nChainLength
Thus, you can safe the first first if+for clause in the first loop and leave away the if, and leave the if+for completely away in the second loop.
for (; nBiTwinSeq < nChainLength; nBiTwinSeq++)
{
[...]
//if (nBiTwinSeq < nChainLength)
for (unsigned int nVariableMultiplier = nSolvedMultiplier; nVariableMultiplier < nMaxSieveSize; nVariableMultiplier += nPrime)
vfCompositeBiTwin[nVariableMultiplier] = true;
if (((nBiTwinSeq & 1u) == 0))
for (unsigned int nVariableMultiplier = nSolvedMultiplier; nVariableMultiplier < nMaxSieveSize; nVariableMultiplier += nPrime)
vfCompositeCunningham1[nVariableMultiplier] = true;
else
for (unsigned int nVariableMultiplier = nSolvedMultiplier; nVariableMultiplier < nMaxSieveSize; nVariableMultiplier += nPrime)
vfCompositeCunningham2[nVariableMultiplier] = true;
[...]
for (; nBiTwinSeq < 2 * nChainLength; nBiTwinSeq++)
{
[...]
//if (nBiTwinSeq < nChainLength)
// for (unsigned int nVariableMultiplier = nSolvedMultiplier; nVariableMultiplier < nMaxSieveSize; nVariableMultiplier += nPrime)
// vfCompositeBiTwin[nVariableMultiplier] = true;
if (((nBiTwinSeq & 1u) == 0))
for (unsigned int nVariableMultiplier = nSolvedMultiplier; nVariableMultiplier < nMaxSieveSize; nVariableMultiplier += nPrime)
vfCompositeCunningham1[nVariableMultiplier] = true;
else
for (unsigned int nVariableMultiplier = nSolvedMultiplier; nVariableMultiplier < nMaxSieveSize; nVariableMultiplier += nPrime)
vfCompositeCunningham2[nVariableMultiplier] = true;
July 10, 2013, 03:29:25 PM
I think it'd be ideal to use a 2D array with the three composite values stored sequentially in memory as single bits each
Probably should be a std::bitset datatype too
Probably should be a std::bitset datatype too
Jump to: