dga
|
|
March 29, 2014, 06:58:16 PM |
|
Hi, all - I've posted b14 source and binaries for the fastrie xptMiner: - Binaries: http://www.cs.cmu.edu/~dga/crypto/ric/- Source: https://github.com/dave-andersen/fastrie- ChangeLog: https://github.com/dave-andersen/fastrie/blob/master/ChangeLog- README: http://www.cs.cmu.edu/~dga/crypto/ric/readme.htmlThis is a speed-boost release targeting larger sieves, and the binaries are now linked against gmp 6.0.0a, which provides faster code targeting avx and avx2 in particular. Sandy Bridge, Ivy Bridge, and Haswell machines should see a very reasonable 5-15% speedup. The larger sieve support comes from borrowing a trick from a00k's miner, which reduces memory consumption with sieves > 500m and slightly improves speed. Older, slower machines will probably not get much of a boost from this release, but newer, faster boxes may benefit from a larger sieve - I'm seeing 10-20% speedups on i7-4770 (Haswell) CPUs. Thanks to the folks on ypool for kicking the tires on this. As always, there are likely to be bugs, but hopefully not too many. Please do read the README before worrying about some of them, and before tweaking the sieve size too much.
|
|
|
|
toto408
Newbie
Offline
Activity: 8
Merit: 0
|
|
March 29, 2014, 07:34:13 PM |
|
Hi, all - I've posted b14 source and binaries for the fastrie xptMiner: - Binaries: http://www.cs.cmu.edu/~dga/crypto/ric/- Source: https://github.com/dave-andersen/fastrie- ChangeLog: https://github.com/dave-andersen/fastrie/blob/master/ChangeLog- README: http://www.cs.cmu.edu/~dga/crypto/ric/readme.htmlThis is a speed-boost release targeting larger sieves, and the binaries are now linked against gmp 6.0.0a, which provides faster code targeting avx and avx2 in particular. Sandy Bridge, Ivy Bridge, and Haswell machines should see a very reasonable 5-15% speedup. The larger sieve support comes from borrowing a trick from a00k's miner, which reduces memory consumption with sieves > 500m and slightly improves speed. Older, slower machines will probably not get much of a boost from this release, but newer, faster boxes may benefit from a larger sieve - I'm seeing 10-20% speedups on i7-4770 (Haswell) CPUs. Thanks to the folks on ypool for kicking the tires on this. As always, there are likely to be bugs, but hopefully not too many. Please do read the README before worrying about some of them, and before tweaking the sieve size too much. Thanks for your work You deserve your automatic donation Any change to release the AVX2 version for Windows?
|
|
|
|
northranger79510
Sr. Member
Offline
Activity: 308
Merit: 250
Riecoin and Huntercoin to rule all!
|
|
March 29, 2014, 07:44:02 PM |
|
Hi, all - I've posted b14 source and binaries for the fastrie xptMiner: - Binaries: http://www.cs.cmu.edu/~dga/crypto/ric/- Source: https://github.com/dave-andersen/fastrie- ChangeLog: https://github.com/dave-andersen/fastrie/blob/master/ChangeLog- README: http://www.cs.cmu.edu/~dga/crypto/ric/readme.htmlThis is a speed-boost release targeting larger sieves, and the binaries are now linked against gmp 6.0.0a, which provides faster code targeting avx and avx2 in particular. Sandy Bridge, Ivy Bridge, and Haswell machines should see a very reasonable 5-15% speedup. The larger sieve support comes from borrowing a trick from a00k's miner, which reduces memory consumption with sieves > 500m and slightly improves speed. Older, slower machines will probably not get much of a boost from this release, but newer, faster boxes may benefit from a larger sieve - I'm seeing 10-20% speedups on i7-4770 (Haswell) CPUs. Thanks to the folks on ypool for kicking the tires on this. As always, there are likely to be bugs, but hopefully not too many. Please do read the README before worrying about some of them, and before tweaking the sieve size too much. Thanks dga, I am glad we have a great Riecoin supporter like you.
|
|
|
|
vancsj
Member
Offline
Activity: 85
Merit: 10
|
|
March 29, 2014, 08:32:20 PM |
|
Hi, dga, could you show me how to compile your code under mingw?I tried to compile your source under mingw-w64, and got the following error: "collect2.exe: error: ld returned 116 exit status", and sadly I cannot find out what's happening:( Thanks a lot. Hi, all - I've posted b14 source and binaries for the fastrie xptMiner: - Binaries: http://www.cs.cmu.edu/~dga/crypto/ric/- Source: https://github.com/dave-andersen/fastrie- ChangeLog: https://github.com/dave-andersen/fastrie/blob/master/ChangeLog- README: http://www.cs.cmu.edu/~dga/crypto/ric/readme.htmlThis is a speed-boost release targeting larger sieves, and the binaries are now linked against gmp 6.0.0a, which provides faster code targeting avx and avx2 in particular. Sandy Bridge, Ivy Bridge, and Haswell machines should see a very reasonable 5-15% speedup. The larger sieve support comes from borrowing a trick from a00k's miner, which reduces memory consumption with sieves > 500m and slightly improves speed. Older, slower machines will probably not get much of a boost from this release, but newer, faster boxes may benefit from a larger sieve - I'm seeing 10-20% speedups on i7-4770 (Haswell) CPUs. Thanks to the folks on ypool for kicking the tires on this. As always, there are likely to be bugs, but hopefully not too many. Please do read the README before worrying about some of them, and before tweaking the sieve size too much.
|
RIC solo mining with XPT miner @ zjuer.net:10034
|
|
|
surfer43
Sr. Member
Offline
Activity: 560
Merit: 250
"Trading Platform of The Future!"
|
|
March 29, 2014, 08:35:25 PM |
|
stratum anyone?
|
|
|
|
vancsj
Member
Offline
Activity: 85
Merit: 10
|
|
March 29, 2014, 08:40:17 PM |
|
And btw it works fine when using MPIR, the problem occurs only when GMP is enabled. Hi, dga, could you show me how to compile your code under mingw?I tried to compile your source under mingw-w64, and got the following error: "collect2.exe: error: ld returned 116 exit status", and sadly I cannot find out what's happening:( Thanks a lot. Hi, all - I've posted b14 source and binaries for the fastrie xptMiner: - Binaries: http://www.cs.cmu.edu/~dga/crypto/ric/- Source: https://github.com/dave-andersen/fastrie- ChangeLog: https://github.com/dave-andersen/fastrie/blob/master/ChangeLog- README: http://www.cs.cmu.edu/~dga/crypto/ric/readme.htmlThis is a speed-boost release targeting larger sieves, and the binaries are now linked against gmp 6.0.0a, which provides faster code targeting avx and avx2 in particular. Sandy Bridge, Ivy Bridge, and Haswell machines should see a very reasonable 5-15% speedup. The larger sieve support comes from borrowing a trick from a00k's miner, which reduces memory consumption with sieves > 500m and slightly improves speed. Older, slower machines will probably not get much of a boost from this release, but newer, faster boxes may benefit from a larger sieve - I'm seeing 10-20% speedups on i7-4770 (Haswell) CPUs. Thanks to the folks on ypool for kicking the tires on this. As always, there are likely to be bugs, but hopefully not too many. Please do read the README before worrying about some of them, and before tweaking the sieve size too much.
|
RIC solo mining with XPT miner @ zjuer.net:10034
|
|
|
Wenzel745
Member
Offline
Activity: 61
Merit: 10
I'll use crypto to buy a Fiat
|
|
March 29, 2014, 10:52:04 PM |
|
Hey guys, I've got about 30 i7 2600's I might want to have mining riecoin. Any idea how I could calculate my rie/day? Can't seem to find any listing of speeds or a calculator. Thanks!
|
BTC: 163pZXhATaWiuGAX9o9y6PuKCF8ipDWnJH HVC: HJWFdgUJPEw1oiLckBFPBzs8vCTLokCGgd
|
|
|
bsunau7
Member
Offline
Activity: 114
Merit: 10
|
|
March 30, 2014, 12:14:11 AM |
|
Hi, all - I've posted b14 source and binaries for the fastrie xptMiner: - Binaries: http://www.cs.cmu.edu/~dga/crypto/ric/- Source: https://github.com/dave-andersen/fastrie- ChangeLog: https://github.com/dave-andersen/fastrie/blob/master/ChangeLog- README: http://www.cs.cmu.edu/~dga/crypto/ric/readme.htmlThis is a speed-boost release targeting larger sieves, and the binaries are now linked against gmp 6.0.0a, which provides faster code targeting avx and avx2 in particular. Sandy Bridge, Ivy Bridge, and Haswell machines should see a very reasonable 5-15% speedup. The larger sieve support comes from borrowing a trick from a00k's miner, which reduces memory consumption with sieves > 500m and slightly improves speed. Older, slower machines will probably not get much of a boost from this release, but newer, faster boxes may benefit from a larger sieve - I'm seeing 10-20% speedups on i7-4770 (Haswell) CPUs. Thanks to the folks on ypool for kicking the tires on this. As always, there are likely to be bugs, but hopefully not too many. Please do read the README before worrying about some of them, and before tweaking the sieve size too much. Just had a very quick look over the code and I do my sieve in phases which might help speed things up a little more (warning my system does not have a hardware divide so I see the benefits very clearly, x86_64 might not see any speed-ups at all). Phase 1. primes smaller than 2*primorial (I use 210). A normal sieve with a fast exit eg. if(!(psieve[j>>5] & ( 1U << (j & 0x1f)))) break; Phase 2. The next "few hundred primes" Add the "remainder to large" test. Doing this test early in the sieve slows the sieve as the test mostly fails which is why I do it later eg. if(tmp & 0xffffffe0UL) continue; Only when the remainder has a greater than 50% chance of passing the test does it becomes time efficient to have this test. Phase 3. The last few hundred thousand primes. I do this in line with the scanner but the main difference is a bulk check 32 candidates at a time eg. if(!psieve[j>>5]) { j += 31; offset += 210*31; continue; } This needs candidate density to be less that ~1 in 64 candidates which is why you need to sieve the "first few hundred" before you get benefit. Regards and as always check my logic, -- bsunau7
|
|
|
|
dga
|
|
March 30, 2014, 01:02:56 AM |
|
Just had a very quick look over the code and I do my sieve in phases which might help speed things up a little more (warning my system does not have a hardware divide so I see the benefits very clearly, x86_64 might not see any speed-ups at all). Phase 1. primes smaller than 2*primorial (I use 210). A normal sieve with a fast exit eg. if(!(psieve[j>>5] & ( 1U << (j & 0x1f)))) break; Phase 2. The next "few hundred primes" Add the "remainder to large" test. Doing this test early in the sieve slows the sieve as the test mostly fails which is why I do it later eg. if(tmp & 0xffffffe0UL) continue; Only when the remainder has a greater than 50% chance of passing the test does it becomes time efficient to have this test. Phase 3. The last few hundred thousand primes. I do this in line with the scanner but the main difference is a bulk check 32 candidates at a time eg. if(!psieve[j>>5]) { j += 31; offset += 210*31; continue; } This needs candidate density to be less that ~1 in 64 candidates which is why you need to sieve the "first few hundred" before you get benefit. Regards and as always check my logic, Perhaps I'm misunderstanding, but: (a) Using the 40th primorial (plus or minus depending on which of the miners you're talking about) means that you never sieve factors that fit into a word anyway. (b) The majority of time in my code is spent doing three things, in order: - Fermat primality test (gmp) - Calculating T_rounded_up % p (gmp) - Sieving large primes that still occur multiple times in the maximum number of nonces (primes under 2^29). Most of this time is actually spent asking one thing: if (offset < sieve_size) which mostly fails with a sieve of 8M entries and a prime of, e.g., 100m. My guess, though I might be wrong, is that a lot of the optimizations you're looking at start to become less dominant when you go for a really huge primorial. For example, almost _no_ time is spent in checking the actual sieve - as far as I can tell, there's basically zero benefit to trying to optimize finding candidates. The code spends somewhere between 1-2 seconds doing primality testing for each iteration through the sieve (8 million bits). The time to check each bit position is a few tens of microseconds of that 1-2 seconds.
|
|
|
|
bsunau7
Member
Offline
Activity: 114
Merit: 10
|
|
March 30, 2014, 01:11:32 AM |
|
Perhaps I'm misunderstanding, but:
(a) Using the 40th primorial (plus or minus depending on which of the miners you're talking about) means that you never sieve factors that fit into a word anyway.
(b) The majority of time in my code is spent doing three things, in order: - Fermat primality test (gmp) - Calculating T_rounded_up % p (gmp) - Sieving large primes that still occur multiple times in the maximum number of nonces (primes under 2^29). Most of this time is actually spent asking one thing: if (offset < sieve_size) which mostly fails with a sieve of 8M entries and a prime of, e.g., 100m.
My guess, though I might be wrong, is that a lot of the optimizations you're looking at start to become less dominant when you go for a really huge primorial. For example, almost _no_ time is spent in checking the actual sieve - as far as I can tell, there's basically zero benefit to trying to optimize finding candidates. The code spends somewhere between 1-2 seconds doing primality testing for each iteration through the sieve (8 million bits). The time to check each bit position is a few tens of microseconds of that 1-2 seconds.
Ah! Mine is a 32bit machine so I've kept everything 32bits or less so I don't have the issue in (a). Likewise it becomes inefficient for me to sieve primes larger than a million which mitigates out some of (b). Regards, -- bsunau7
|
|
|
|
northranger79510
Sr. Member
Offline
Activity: 308
Merit: 250
Riecoin and Huntercoin to rule all!
|
|
March 30, 2014, 08:27:44 AM |
|
How are other pools doing right now?
|
|
|
|
agx.io
Member
Offline
Activity: 84
Merit: 10
|
|
March 30, 2014, 02:54:28 PM |
|
You asked. We listened. Lots of upgrades to Austin Global Exchange launched overnight. Faster trades. Faster page loads. Fewer clicks. Intuitive layout. More markets. Dynamic content. Integrated chat. And more! You can also earn 1% trading bonuses on VC, NOBL, and DGB! Reach out to us, social@agx.io, if you're a developer wanting to sponsor a 1% trading promo on another coin. We're always looking for great partners. Check out agx.io to trade RIC/BTC, learn more about the 1% promo, and see what we've been working on! - The Austin Global TeamFind us at: agx.io bitcointalk.org/index.php?topic=507474 bitcointalk handles: "agx.io," "AustinGlobal" twitter.com/AustinGlobalX austinglobal.tumblr.com
|
|
|
|
primer10
|
|
March 30, 2014, 03:13:36 PM |
|
Hi, all - I've posted b14 source and binaries for the fastrie xptMiner: - Binaries: http://www.cs.cmu.edu/~dga/crypto/ric/- Source: https://github.com/dave-andersen/fastrie- ChangeLog: https://github.com/dave-andersen/fastrie/blob/master/ChangeLog- README: http://www.cs.cmu.edu/~dga/crypto/ric/readme.htmlThis is a speed-boost release targeting larger sieves, and the binaries are now linked against gmp 6.0.0a, which provides faster code targeting avx and avx2 in particular. Sandy Bridge, Ivy Bridge, and Haswell machines should see a very reasonable 5-15% speedup. The larger sieve support comes from borrowing a trick from a00k's miner, which reduces memory consumption with sieves > 500m and slightly improves speed. Older, slower machines will probably not get much of a boost from this release, but newer, faster boxes may benefit from a larger sieve - I'm seeing 10-20% speedups on i7-4770 (Haswell) CPUs. Thanks to the folks on ypool for kicking the tires on this. As always, there are likely to be bugs, but hopefully not too many. Please do read the README before worrying about some of them, and before tweaking the sieve size too much. Thanks dga!! I compiled b13 against gmp 6, ran for 11 hrs. I tried b14, also against gmp 6 for almost 11hrs.. then I switched back to b13. I am using i7-4770 and so far it seems b13 is better, in terms of shares/h reported on ypool .. Anyone else has similar results to mine?
|
|
|
|
surfer43
Sr. Member
Offline
Activity: 560
Merit: 250
"Trading Platform of The Future!"
|
|
March 30, 2014, 03:49:27 PM |
|
How are other pools doing right now?
upcpu found 4 blocks last 120 blocks. infinitypool yet to find a block...
|
|
|
|
northranger79510
Sr. Member
Offline
Activity: 308
Merit: 250
Riecoin and Huntercoin to rule all!
|
|
March 30, 2014, 07:38:14 PM |
|
How are other pools doing right now?
upcpu found 4 blocks last 120 blocks. infinitypool yet to find a block... Any reasons for this?
|
|
|
|
jussdf
Newbie
Offline
Activity: 28
Merit: 0
|
|
March 30, 2014, 07:48:35 PM |
|
|
|
|
|
Bigtruck45
Newbie
Offline
Activity: 37
Merit: 0
|
|
March 30, 2014, 08:31:54 PM |
|
Was just wondering, how powerful a computer/cpu is needed to at least be able to mine a block? I'm currently on ypool with Dave's optimized miner and my workers never find any at all.
I'm running an i5 4570 4 core with 8GB RAM on Ypool. Found 2 blocks since start of riecoin for the pool. 142 coins as my share so far.
|
|
|
|
northranger79510
Sr. Member
Offline
Activity: 308
Merit: 250
Riecoin and Huntercoin to rule all!
|
|
March 30, 2014, 11:34:10 PM |
|
Low activity on this thread right now. :O
|
|
|
|
dga
|
|
March 31, 2014, 12:17:45 AM |
|
Sorry - I'm clueless about MPIR. And btw it works fine when using MPIR, the problem occurs only when GMP is enabled. Hi, dga, could you show me how to compile your code under mingw?I tried to compile your source under mingw-w64, and got the following error: "collect2.exe: error: ld returned 116 exit status", and sadly I cannot find out what's happening:( Thanks a lot. Hi, all - I've posted b14 source and binaries for the fastrie xptMiner: - Binaries: http://www.cs.cmu.edu/~dga/crypto/ric/- Source: https://github.com/dave-andersen/fastrie- ChangeLog: https://github.com/dave-andersen/fastrie/blob/master/ChangeLog- README: http://www.cs.cmu.edu/~dga/crypto/ric/readme.htmlThis is a speed-boost release targeting larger sieves, and the binaries are now linked against gmp 6.0.0a, which provides faster code targeting avx and avx2 in particular. Sandy Bridge, Ivy Bridge, and Haswell machines should see a very reasonable 5-15% speedup. The larger sieve support comes from borrowing a trick from a00k's miner, which reduces memory consumption with sieves > 500m and slightly improves speed. Older, slower machines will probably not get much of a boost from this release, but newer, faster boxes may benefit from a larger sieve - I'm seeing 10-20% speedups on i7-4770 (Haswell) CPUs. Thanks to the folks on ypool for kicking the tires on this. As always, there are likely to be bugs, but hopefully not too many. Please do read the README before worrying about some of them, and before tweaking the sieve size too much.
|
|
|
|
dga
|
|
March 31, 2014, 12:19:57 AM |
|
God THe deficullty is going crazy
Max difficulty achieved thus far is 1712: http://www.cs.cmu.edu/~dga/crypto/ric/diff_offset_2014_03_27.pngWhich is also the current diff. I'll get this graph automated over the weekend for at least daily updates so I can stop squawking about it, or commit the tools to generate it into the fastrie github so that someone else can do it easily. An automated graph would be fantastic! Well, it's not automated (yet), but I've checked in the plot generation scripts into the fastrie tree so that anyone can generate their own. Warning: They're a silly quick hack! Someone should rewrite them. I'd love to put an improved version in there... https://github.com/dave-andersen/fastrie/tree/master/analysis
|
|
|
|
|