Bitcoin Forum
October 12, 2024, 10:14:36 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 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 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 ... 199 »
  Print  
Author Topic: [XPM] [ANN] Primecoin Release - First Scientific Computing Cryptocurrency  (Read 688723 times)
nmersulypnem
Full Member
***
Offline Offline

Activity: 238
Merit: 100


View Profile
July 10, 2013, 07:17:10 PM
 #1221

So I just updated to the most recent version of the miner from Sunny King, and now my ten minute rolling average pps is ~600 pps (custom calculation script) on 8 threads. Woo!

Now to see if that correlates to finding more blocks.

Everyone update and stop bitching about people "stealing blocks", lol.



Edit: I forgot to mention that my previous average about 42 pps. Additionally, I compiled the update will the default options on OSX, running on a quad core 2.2 GHz Intel core i7 on macbook pro.

Did you do this without reducing the maxseivesize?  'cause I think that skews the pps number.  ...but there are definitely places all over for optimization...
Fablio2
Sr. Member
****
Offline Offline

Activity: 464
Merit: 252



View Profile
July 10, 2013, 07:17:46 PM
 #1222

Everyone update and stop bitching about people "stealing blocks", lol.
How to update? Most of the miners are not programmers to get into code.
Scott J
Legendary
*
Offline Offline

Activity: 1792
Merit: 1000


View Profile
July 10, 2013, 07:18:00 PM
 #1223

So I just updated to the most recent version of the miner from Sunny King, and now my ten minute rolling average pps is ~600 pps (custom calculation script) on 8 threads. Woo!

Now to see if that correlates to finding more blocks.

Everyone update and stop bitching about people "stealing blocks", lol.



Edit: I forgot to mention that my previous average about 42 pps. Additionally, I compiled the update will the default options on OSX, running on a quad core 2.2 GHz Intel core i7 on macbook pro.
Sounds good!

How can a noob on windows 7 take Suny's github code and update their miner?
refer_2_me
Full Member
***
Offline Offline

Activity: 213
Merit: 100



View Profile
July 10, 2013, 07:20:17 PM
 #1224

So I just updated to the most recent version of the miner from Sunny King, and now my ten minute rolling average pps is ~600 pps (custom calculation script) on 8 threads. Woo!

Now to see if that correlates to finding more blocks.

Everyone update and stop bitching about people "stealing blocks", lol.



Edit: I forgot to mention that my previous average about 42 pps. Additionally, I compiled the update will the default options on OSX, running on a quad core 2.2 GHz Intel core i7 on macbook pro.

Did you do this without reducing the maxseivesize?  'cause I think that skews the pps number.  ...but there are definitely places all over for optimization...

I did not make any changes to the code.

To update: check the source out from github here: https://github.com/primecoin/primecoin

I'm not a windows guy, so I can't help you with compiling on windows, sorry.

BTC: 1reFerkRnftob5YvbB112bbuwepC9XYLj
XPM: APQpPZCfEz3kejrYTfyACY1J9HrjnRf34Y
nmersulypnem
Full Member
***
Offline Offline

Activity: 238
Merit: 100


View Profile
July 10, 2013, 07:27:34 PM
 #1225



So seriously, are people sharing optimization tips somewhere?  I've made a few myself, but I'm sure other people have different ones.   If you want to trade optimizations, just PM me.
refer_2_me
Full Member
***
Offline Offline

Activity: 213
Merit: 100



View Profile
July 10, 2013, 07:29:36 PM
 #1226



So seriously, are people sharing optimization tips somewhere?  I've made a few myself, but I'm sure other people have different ones.   If you want to trade optimizations, just PM me.

Possibly, but if you are referring to my post, the optimizations (what ever they were) were made by the original dev Sunny King, and are available in the git hub repo (linked in my post above).

BTC: 1reFerkRnftob5YvbB112bbuwepC9XYLj
XPM: APQpPZCfEz3kejrYTfyACY1J9HrjnRf34Y
nmersulypnem
Full Member
***
Offline Offline

Activity: 238
Merit: 100


View Profile
July 10, 2013, 07:40:02 PM
 #1227

I am not.  Looking at the most current codebase, there is definitely more to be done...
Petr1fied
Hero Member
*****
Offline Offline

Activity: 630
Merit: 502


View Profile
July 10, 2013, 07:42:51 PM
 #1228


Or you could use mine which gives you the prime numbers:

http://primeblock.kicks-ass.net/block_crawler.php
Mike270
Full Member
***
Offline Offline

Activity: 158
Merit: 100


View Profile
July 10, 2013, 07:50:43 PM
 #1229

Ok, so I'm probably hurting my income, but sharing some hints for optimizations:
A quick'n'dirty profiling run showed that we spend very much time in memory allocations, so I am trying to eliminate some of them.

-did the headerhash mod outlined earlier

-did the time limit on Weave() from Sunny King

-removed some printf's , especially
printf("MineProbablePrimeChain() : new sieve (%u/%u) ready in %uus\n", psieve->GetCandidateCount(), nMaxSieveSize, (unsigned int) (GetTimeMicros() - nStart));
from prime.cpp since it's the only call to the rather expensive GetCandidateCount

-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, PrimeTableGetNextPrime and PrimeTableGetPreviousPrime: Use upper_bound/lower_bound instead of linear search:
// Get next prime number of p
bool PrimeTableGetNextPrime(unsigned int& p)
{
    std::vector<unsigned int>::iterator foundelement=upper_bound(vPrimes.begin(), vPrimes.end(),p);
    if (foundelement!=vPrimes.end()){
        p=*foundelement;
        return true;
    }
    return false;
}

// Get previous prime number of p
bool PrimeTableGetPreviousPrime(unsigned int& p)
{
    std::vector<unsigned int>::iterator foundelement=lower_bound(vPrimes.begin(), vPrimes.end(),p);
    if (foundelement!=vPrimes.end()){
        p=*--foundelement;
        return true;
    }
    return false;
}

- 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.
Also,
if (((nBiTwinSeq & 1u) == 0))
...
if (((nBiTwinSeq & 1u) == 1u))

can be substituted by

if (((nBiTwinSeq & 1u) == 0))
....
else
.....


-prime.h: Removed nSieveSize and replaced all occurrences with nMaxSieveSize. Removed nSieveSize from the initializer as it's become obsolete.

-prime.h: Changed
<     std::vector<bool> vfCompositeCunningham1;
<     std::vector<bool> vfCompositeCunningham2;
<     std::vector<bool> vfCompositeBiTwin;
---
>     bool vfCompositeCunningham1[1000000];
>     bool vfCompositeCunningham2[1000000];
>     bool vfCompositeBiTwin[1000000];
Thus, we should save on quite a few mallocs.


refer_2_me
Full Member
***
Offline Offline

Activity: 213
Merit: 100



View Profile
July 10, 2013, 07:55:32 PM
 #1230

Ok, so I'm probably hurting my income, but sharing some hints for optimizations:
A quick'n'dirty profiling run showed that we spend very much time in memory allocations, so I am trying to eliminate some of them.

-did the headerhash mod outlined earlier

-did the time limit on Weave() from Sunny King

-removed some printf's , especially
printf("MineProbablePrimeChain() : new sieve (%u/%u) ready in %uus\n", psieve->GetCandidateCount(), nMaxSieveSize, (unsigned int) (GetTimeMicros() - nStart));
from prime.cpp since it's the only call to the rather expensive GetCandidateCount

-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, PrimeTableGetNextPrime and PrimeTableGetPreviousPrime: Use upper_bound/lower_bound instead of linear search:
// Get next prime number of p
bool PrimeTableGetNextPrime(unsigned int& p)
{
    std::vector<unsigned int>::iterator foundelement=upper_bound(vPrimes.begin(), vPrimes.end(),p);
    if (foundelement!=vPrimes.end()){
        p=*foundelement;
        return true;
    }
    return false;
}

// Get previous prime number of p
bool PrimeTableGetPreviousPrime(unsigned int& p)
{
    std::vector<unsigned int>::iterator foundelement=lower_bound(vPrimes.begin(), vPrimes.end(),p);
    if (foundelement!=vPrimes.end()){
        p=*--foundelement;
        return true;
    }
    return false;
}

- 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.
Also,
if (((nBiTwinSeq & 1u) == 0))
...
if (((nBiTwinSeq & 1u) == 1u))

can be substituted by

if (((nBiTwinSeq & 1u) == 0))
....
else
.....


-prime.h: Removed nSieveSize and replaced all occurrences with nMaxSieveSize. Removed nSieveSize from the initializer as it's become obsolete.

-prime.h: Changed
<     std::vector<bool> vfCompositeCunningham1;
<     std::vector<bool> vfCompositeCunningham2;
<     std::vector<bool> vfCompositeBiTwin;
---
>     bool vfCompositeCunningham1[1000000];
>     bool vfCompositeCunningham2[1000000];
>     bool vfCompositeBiTwin[1000000];
Thus, we should save on quite a few mallocs.




Sweet, I haven't tried these out yet, but were you able get a measurable speed up?

BTC: 1reFerkRnftob5YvbB112bbuwepC9XYLj
XPM: APQpPZCfEz3kejrYTfyACY1J9HrjnRf34Y
8bitPunk
Member
**
Offline Offline

Activity: 70
Merit: 10



View Profile
July 10, 2013, 08:01:21 PM
 #1231

Thanks for sharing Mike270 Smiley

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

BTC 18bPunkuginRBm1Xz9mcgj8mWJnHDAW5Th | Ł LTCgXEdyBdoQ9WdF6JHi7Pa2EWtzbDjG76 | Ψ ATEBiTLkLpAYeW5hQknUfSvnb7Abbgegku
gatra
Hero Member
*****
Offline Offline

Activity: 583
Merit: 505


CTO @ Flixxo, Riecoin dev


View Profile WWW
July 10, 2013, 08:03:43 PM
 #1232

Ok, so I'm probably hurting my income, but sharing some hints for optimizations:
A quick'n'dirty profiling run showed that we spend very much time in memory allocations, so I am trying to eliminate some of them.

-did the headerhash mod outlined earlier

-did the time limit on Weave() from Sunny King

-removed some printf's , especially
printf("MineProbablePrimeChain() : new sieve (%u/%u) ready in %uus\n", psieve->GetCandidateCount(), nMaxSieveSize, (unsigned int) (GetTimeMicros() - nStart));
from prime.cpp since it's the only call to the rather expensive GetCandidateCount

-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, PrimeTableGetNextPrime and PrimeTableGetPreviousPrime: Use upper_bound/lower_bound instead of linear search:
// Get next prime number of p
bool PrimeTableGetNextPrime(unsigned int& p)
{
    std::vector<unsigned int>::iterator foundelement=upper_bound(vPrimes.begin(), vPrimes.end(),p);
    if (foundelement!=vPrimes.end()){
        p=*foundelement;
        return true;
    }
    return false;
}

// Get previous prime number of p
bool PrimeTableGetPreviousPrime(unsigned int& p)
{
    std::vector<unsigned int>::iterator foundelement=lower_bound(vPrimes.begin(), vPrimes.end(),p);
    if (foundelement!=vPrimes.end()){
        p=*--foundelement;
        return true;
    }
    return false;
}

- 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.
Also,
if (((nBiTwinSeq & 1u) == 0))
...
if (((nBiTwinSeq & 1u) == 1u))

can be substituted by

if (((nBiTwinSeq & 1u) == 0))
....
else
.....


-prime.h: Removed nSieveSize and replaced all occurrences with nMaxSieveSize. Removed nSieveSize from the initializer as it's become obsolete.

-prime.h: Changed
<     std::vector<bool> vfCompositeCunningham1;
<     std::vector<bool> vfCompositeCunningham2;
<     std::vector<bool> vfCompositeBiTwin;
---
>     bool vfCompositeCunningham1[1000000];
>     bool vfCompositeCunningham2[1000000];
>     bool vfCompositeBiTwin[1000000];
Thus, we should save on quite a few mallocs.




did you measure the speedup of every change? the first rule of optimization is: measure! otherwise you may be making it worse without knowing...
just a few comments:
those bool arrays are probably no much better than the vectors. Each bool takes 1 byte of RAM. If you want to make that faster you have use an array of ints that is 1/32 of the size, and encode each bool in a single bit of the 32 bits. That will make arrays shorter, speeding up mallocs and making more bools fit in the cache.

Also, probably changing the call to size() by a variable, and splitting the loop look like not worth it. However the upper and lower_bound are definitly better


           ▄▄▄██████████▄▄▄
       ▄▄██
██████████████████▄▄
     ▄█
█████▀████████████▀██████▄
   ▄█
█████████████████████████████▄
  ▄█
█████████▄█▀▀██████████████████▄
 ▄█
███████████▀██████▄▄█████▄███████▄
▄█
██████████▀██▄▄▄▄██▀▀▀▀▀███████████▄
█████████████▀▀██▀████████▀▀████████
█████████████▄█▀████████████████████
████████▀▀▀▀██▀▀▀▀██████████████████
▀█
██████▀▀▀▀██▀▀▀▀███████████████████▀
 ▀█
███████▄████▄▄███████████████████▀
  ▀█
███████████████████████████████▀
   ▀█
█████████████████████████████▀
     ▀█
█████▄████████████▄██████▀
       ▀▀██
██████████████████▀▀
           ▀▀▀██████████▀▀▀
riecoin       ▄▄█████████▄▄
    ▄██▀▀         ▀▀██▄
  ▄██▀              ▀██▄
 ▄██     ██▄▄          ██▄
▄██      █████▄▄        ██▄
██       ████████▄▄      ██
██       ███████████▄    ██
██       ██████████▀     ██
▀██      ███████▀       ██▀
 ▀██     ████▀         ██▀
  ▀██▄   █▀          ▄██▀
    ▀██▄▄         ▄▄██▀
       ▀▀█████████▀▀
.flixxo   
LazyOtto
Sr. Member
****
Offline Offline

Activity: 476
Merit: 250


View Profile
July 10, 2013, 08:05:21 PM
 #1233

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
What does that mean?
gateway
Hero Member
*****
Offline Offline

Activity: 552
Merit: 500


View Profile
July 10, 2013, 08:05:51 PM
 #1234

whats a decent per sec rate? I'm seeing on my machine that im also working on.. "primespersec" : 76.. windows 7 64bit.. blah blah blah
Mike270
Full Member
***
Offline Offline

Activity: 158
Merit: 100


View Profile
July 10, 2013, 08:06:55 PM
 #1235

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)
Impaler
Sr. Member
****
Offline Offline

Activity: 826
Merit: 250

CryptoTalk.Org - Get Paid for every Post!


View Profile
July 10, 2013, 08:07:08 PM
Last edit: July 10, 2013, 09:14:49 PM by Impaler
 #1236

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 amongst all coins.

 
                                . ██████████.
                              .████████████████.
                           .██████████████████████.
                        -█████████████████████████████
                     .██████████████████████████████████.
                  -█████████████████████████████████████████
               -███████████████████████████████████████████████
           .-█████████████████████████████████████████████████████.
        .████████████████████████████████████████████████████████████
       .██████████████████████████████████████████████████████████████.
       .██████████████████████████████████████████████████████████████.
       ..████████████████████████████████████████████████████████████..
       .   .██████████████████████████████████████████████████████.
       .      .████████████████████████████████████████████████.

       .       .██████████████████████████████████████████████
       .    ██████████████████████████████████████████████████████
       .█████████████████████████████████████████████████████████████.
        .███████████████████████████████████████████████████████████
           .█████████████████████████████████████████████████████
              .████████████████████████████████████████████████
                   ████████████████████████████████████████
                      ██████████████████████████████████
                          ██████████████████████████
                             ████████████████████
                               ████████████████
                                   █████████
CryptoTalk.org| 
MAKE POSTS AND EARN BTC!
🏆
bidji29
Sr. Member
****
Offline Offline

Activity: 392
Merit: 250


View Profile
July 10, 2013, 08:11:34 PM
 #1237

Thanks Mike!
I did some change but i don't understand some of them, like those three :



-did the headerhash mod outlined earlier

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


 Somebody can explain how to make those changes?

http://www.freebieservers.com/  100% FREE GAME SERVERS
tacotime
Legendary
*
Offline Offline

Activity: 1484
Merit: 1005



View Profile
July 10, 2013, 08:12:36 PM
 #1238

-prime.h: Removed nSieveSize and replaced all occurrences with nMaxSieveSize. Removed nSieveSize from the initializer as it's become obsolete.

-prime.h: Changed
<     std::vector<bool> vfCompositeCunningham1;
<     std::vector<bool> vfCompositeCunningham2;
<     std::vector<bool> vfCompositeBiTwin;
---
>     bool vfCompositeCunningham1[1000000];
>     bool vfCompositeCunningham2[1000000];
>     bool vfCompositeBiTwin[1000000];
Thus, we should save on quite a few mallocs.

Don't forget to initialize the array by adding the following below in place of the other initialization

Code:
        for (int i = 0; i<1000000; ++i){
            vfCompositeCunningham1[i] = false;
            vfCompositeCunningham2[i] = false;
            vfCompositeBiTwin[i] = false;
        }

Code:
XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns
drummerjdb666
Full Member
***
Offline Offline

Activity: 244
Merit: 101



View Profile
July 10, 2013, 08:14:41 PM
 #1239

So I just updated to the most recent version of the miner from Sunny King, and now my ten minute rolling average pps is ~600 pps (custom calculation script) on 8 threads. Woo!

Now to see if that correlates to finding more blocks.

Everyone update and stop bitching about people "stealing blocks", lol.



Edit: I forgot to mention that my previous average about 42 pps. Additionally, I compiled the update will the default options on OSX, running on a quad core 2.2 GHz Intel core i7 on macbook pro.
Sounds good!

How can a noob on windows 7 take Suny's github code and update their miner?

+1
tacotime
Legendary
*
Offline Offline

Activity: 1484
Merit: 1005



View Profile
July 10, 2013, 08:21:21 PM
 #1240

did you measure the speedup of every change? the first rule of optimization is: measure! otherwise you may be making it worse without knowing...
just a few comments:
those bool arrays are probably no much better than the vectors. Each bool takes 1 byte of RAM. If you want to make that faster you have use an array of ints that is 1/32 of the size, and encode each bool in a single bit of the 32 bits. That will make arrays shorter, speeding up mallocs and making more bools fit in the cache.

Also, probably changing the call to size() by a variable, and splitting the loop look like not worth it. However the upper and lower_bound are definitly better

Agreed

Code:
XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns
Pages: « 1 ... 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 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 ... 199 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!