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

jussdf

newbie

Activity: 28

Merit: 0

I was just ready to mining this coin. Grin

northranger79510

sr. member

Activity: 308

Merit: 250

Riecoin and Huntercoin to rule all!

Quote from: surfer43 on March 30, 2014, 10:49:27 AM

Quote from: northranger79510 on March 30, 2014, 03:27:44 AM

How are other pools doing right now?

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

Any reasons for this?

surfer43

sr. member

Activity: 560

Merit: 250

"Trading Platform of The Future!"

Quote from: northranger79510 on March 30, 2014, 03:27:44 AM

How are other pools doing right now?

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

primer10

sr. member

Activity: 249

Merit: 250

Quote from: dga on March 29, 2014, 01: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.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?

agx.io

member

Activity: 84

Merit: 10

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, [email protected], 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

northranger79510

sr. member

Activity: 308

Merit: 250

Riecoin and Huntercoin to rule all!

How are other pools doing right now?

bsunau7

member

Activity: 114

Merit: 10

Quote from: dga on March 29, 2014, 08:02:56 PM

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

dga

hero member

Activity: 737

Merit: 511

Quote from: bsunau7 on March 29, 2014, 07:14:11 PM

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

member

Activity: 114

Merit: 10

Quote from: dga on March 29, 2014, 01: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.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

Wenzel745

member

Activity: 61

Merit: 10

I'll use crypto to buy a Fiat

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!

vancsj

member

Activity: 85

Merit: 10

And btw it works fine when using MPIR, the problem occurs only when GMP is enabled.

Quote from: vancsj on March 29, 2014, 03: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.

Quote from: dga on March 29, 2014, 01: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.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

sr. member

Activity: 560

Merit: 250

"Trading Platform of The Future!"

stratum anyone?

vancsj

member

Activity: 85

Merit: 10

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.

Quote from: dga on March 29, 2014, 01: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.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.

northranger79510

sr. member

Activity: 308

Merit: 250

Riecoin and Huntercoin to rule all!

Quote from: dga on March 29, 2014, 01: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.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.

toto408

newbie

Activity: 8

Merit: 0

Quote from: dga on March 29, 2014, 01: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.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 Cheesy

Any change to release the AVX2 version for Windows?

dga

hero member

Activity: 737

Merit: 511

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.

restless

legendary

Activity: 1151

Merit: 1001

Is there a way to estimate how much shares cpu generates?

bsunau7

member

Activity: 114

Merit: 10

Quote from: otila on March 28, 2014, 02:09:49 PM

Quote from: dga on March 28, 2014, 10:41:26 AM

The folks on ypool just pointed out to me that gmp 6.0.0a has been released. (Thanks!)

fastrie is only 5% faster with 6.0.0a than with 5.1.3 (I have SandyBridge)

11% faster with a custom ARM based miner.

--
bsunau7

northranger79510

sr. member

Activity: 308

Merit: 250

Riecoin and Huntercoin to rule all!

That near 40k buy wall though Cheesy

surfer43

sr. member

Activity: 560

Merit: 250

"Trading Platform of The Future!"

If Chinese looks like Greek to you,
BTC38 launched an English version of their exchange
RIC/CNY market linked.

Looks like btc38 had about twenty times the volume of Mintpal the last 24 hours...

Edit: looks like they only support Facebook for English log in. Huh

Topic: [ANN][RIC] Riecoin: constellations POW *CPU* HARD FORK successful, world record - page 179. (Read 685207 times)

Topic: [ANN][RIC] Riecoin: constellations POW CPU HARD FORK successful, world record - page 179. (Read 685207 times)