[ANN][RIC] Riecoin: constellations POW *CPU* HARD FORK successful, world record

[dga]

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

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

[1714829746]

1714829746

[1714829746]

1714829746

[1714829746]

1714829746

[toto408]

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

This 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]

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

This 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]

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

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

[surfer43]

stratum anyone?

[vancsj]

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

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

[Wenzel745]

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!

[bsunau7]

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

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

Code:

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.

Code:

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.

Code:

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]

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.

Code:

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.

Code:

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.

Code:

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]

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]

How are other pools doing right now?

[agx.io]

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 Team

Find us at:
agx.io
bitcointalk.org/index.php?topic=507474
bitcointalk handles: "agx.io," "AustinGlobal"
twitter.com/AustinGlobalX
austinglobal.tumblr.com

[primer10]

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

This 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]

How are other pools doing right now?

upcpu found 4 blocks last 120 blocks.
infinitypool yet to find a block...

[northranger79510]

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]

I was just ready to mining this coin.

[Bigtruck45]

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]

Low activity on this thread right now. :O

[dga]

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

This 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]

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

Which 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