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

northranger79510

sr. member

Activity: 308

Merit: 250

Riecoin and Huntercoin to rule all!

Quote from: COMKORT on April 02, 2014, 02:42:40 PM

Congratulations! Riecoin was added to COMKORT exchange.

3 MARKETS for RIC

https://comkort.com/market/trade/ric_btc

https://comkort.com/market/trade/ric_ltc

https://comkort.com/market/trade/ric_doge

Great opportunities for alt coin traiding! Join in and enjoy our rewarding BONUS system!

Excellent!. Dont know why you guys don't have more trading volumes though. Traded with you guys to experiment and its pretty smooth.

COMKORT

full member

Activity: 182

Merit: 100

Congratulations! Riecoin was added to COMKORT exchange.

3 MARKETS for RIC

https://comkort.com/market/trade/ric_btc

https://comkort.com/market/trade/ric_ltc

https://comkort.com/market/trade/ric_doge

Great opportunities for alt coin traiding! Join in and enjoy our rewarding BONUS system!

northranger79510

sr. member

Activity: 308

Merit: 250

Riecoin and Huntercoin to rule all!

Sad month for cryptocurrencies right now.

bitcoinvideos

sr. member

Activity: 251

Merit: 250

Quote from: northranger79510 on April 01, 2014, 11:39:24 PM

The Foundation is still verifying that multi-sig works so again, donations and projects will be delayed for another day.

No worries - things are going well still. This is the perfect time to be onboard w/ RIC!

northranger79510

sr. member

Activity: 308

Merit: 250

Riecoin and Huntercoin to rule all!

The Foundation is still verifying that multi-sig works so again, donations and projects will be delayed for another day.

bitcoinvideos

sr. member

Activity: 251

Merit: 250

Don't forget to like us on Facebook: https://www.facebook.com/TheRiecoinCommunity

bitcoinvideos

sr. member

Activity: 251

Merit: 250

New Bitcoin Spinoff Promises Scientific and Mathematical Benefits to the Community

Riecoin is a brand new alternative currency based off of the Bitcoin protocol that searches for new prime numbers and eliminates the traditional e-waste associated with digital mining

FOR IMMEDIATE RELEASE

PRLog (Press Release) - Apr. 1, 2014 - The meteoric rise of Bitcoin as an alternative currency around the world has been in major headlines and continues to be a source of interest for people seeking options in a shaky financial environment. Unfortunately, one of the traditional concerns with Bitcoin revolves around the mining process and its resultant electronic waste. Bitcoin miners typically use electricity to generate the currency, but not much else is generated, creating large amounts of wasted energy. However, a new coin has recently been released based off of the Bitcoin protocol that aims to solve this problem of electronic waste by finding new prime numbers as a by-product of mining.

http://www.prlog.org/12303869-new-bitcoin-spinoff-promises-scientific-and-mathematical-benefits-to-the-community.html

If anyone from the community can help promote it I would certainly appreciate it! Right now the foundation does not have funds set aside for a paid distribution so I am grass roots submitting this to as many places as I can.

remistevens

hero member

Activity: 630

Merit: 501

Quote from: northranger79510 on April 01, 2014, 06:39:00 PM

Foundation members are learning how multisig works to verify once more that donation address works. Please be patient.

Cool stuff, very interested in donating. Nice job with all the setup!

northranger79510

sr. member

Activity: 308

Merit: 250

Riecoin and Huntercoin to rule all!

Foundation members are learning how multisig works to verify once more that donation address works. Please be patient.

dga

hero member

Activity: 737

Merit: 511

Quote from: toto408 on April 01, 2014, 01:27:54 PM

It seems that the lastest versions of gcc support avx2: http://forums.gentoo.org/viewtopic-p-7411324.html#7411324

I'm a genuine noob in all the linux stuff, so unfortunatly I can't help you Undecided

I'll try to dig a little bit more and see if I find something relevant

They do. There's a linux avx2 build up on my website. I'm just not sure how to do it with mingw -- its version of gcc seems to lag behind the current release.

toto408

newbie

Activity: 8

Merit: 0

Quote from: dga on April 01, 2014, 12:45:41 PM

Quote from: toto408 on April 01, 2014, 12:44:35 PM

Quote from: dga on April 01, 2014, 09:33:00 AM

Quote from: cphr on April 01, 2014, 01:45:07 AM

I've compiled custom build(windows 64bit) from jh00 xptminer and dga ric core with gmp 6.0.0(not mpir) and avx-i support (Ivy Bridge processors only).

Build include 1% devfee (hardcoded).

Don't you find it a little odd to rip out someone's existing dev fee when there's a mechanism in there to add your own to the stack and ensure that all of the developers continue to have an incentive to work on the software? I do. So:

There's now an official build for Windows 64bit against gmp 6.0.0a with avx support at:

http://www.cs.cmu.edu/~dga/crypto/ric/

Along with the existing sse4 version. I've automated the build for this platform and will continue to maintain it through future releases. At the same time, I've also added an avx version for Linux. These have my standard dev fee structure - 2% default (1.5% to me, 0.25% jh00, 0.25% clintar), and you can increase or decrease it from the command line or in the source code as you wish.

Any chance to have the AVX2 version as well? Lips sealed

The version of mingw I have doesn't support avx2. Is there one that does? I'm happy to upgrade if it's ubuntu-friendly.

It seems that the lastest versions of gcc support avx2: http://forums.gentoo.org/viewtopic-p-7411324.html#7411324

I'm a genuine noob in all the linux stuff, so unfortunatly I can't help you Undecided

I'll try to dig a little bit more and see if I find something relevant

cphr

newbie

Activity: 9

Merit: 0

Quote from: dga on April 01, 2014, 09:33:00 AM

Quote from: cphr on April 01, 2014, 01:45:07 AM

I've compiled custom build(windows 64bit) from jh00 xptminer and dga ric core with gmp 6.0.0(not mpir) and avx-i support (Ivy Bridge processors only).

Build include 1% devfee (hardcoded).

Don't you find it a little odd to rip out someone's existing dev fee when there's a mechanism in there to add your own to the stack and ensure that all of the developers continue to have an incentive to work on the software? I do. So:

There's now an official build for Windows 64bit against gmp 6.0.0a with avx support at:

http://www.cs.cmu.edu/~dga/crypto/ric/

Along with the existing sse4 version. I've automated the build for this platform and will continue to maintain it through future releases. At the same time, I've also added an avx version for Linux. These have my standard dev fee structure - 2% default (1.5% to me, 0.25% jh00, 0.25% clintar), and you can increase or decrease it from the command line or in the source code as you wish.

cphr, I'd love to talk about a strategy that has the right incentives for everyone. Just like I think it's great for pools to provide a dev fee mechanism to encourage miner innovation, I think it's important for devs and port maintainers to figure out a reasonable standard of expectation for how to split dev fees in a good way. Good outcomes would seem to include:
- Original developers have an incentive to keep developing and improving their software;
- Original developers want to make it easy for platform-porters to do their ports and keep in sync with the dev version;
- Platform-porters want to make awesome platform ports and receive a fair fee for doing so.

Any thoughts on the right way to do this in the future?

dga, you are right. Thank you for advice. I edited my post with new build. Now it's include you default devfee (1.5% dga, 0.25% jh00, 0.25% clintar and 0.25% for me) and it can be disabled from command line, but can't be increased or decreased.

And thank you for your work on this project.

dga

hero member

Activity: 737

Merit: 511

Quote from: toto408 on April 01, 2014, 12:44:35 PM

Quote from: dga on April 01, 2014, 09:33:00 AM

Quote from: cphr on April 01, 2014, 01:45:07 AM

I've compiled custom build(windows 64bit) from jh00 xptminer and dga ric core with gmp 6.0.0(not mpir) and avx-i support (Ivy Bridge processors only).

Build include 1% devfee (hardcoded).

Don't you find it a little odd to rip out someone's existing dev fee when there's a mechanism in there to add your own to the stack and ensure that all of the developers continue to have an incentive to work on the software? I do. So:

There's now an official build for Windows 64bit against gmp 6.0.0a with avx support at:

http://www.cs.cmu.edu/~dga/crypto/ric/

Along with the existing sse4 version. I've automated the build for this platform and will continue to maintain it through future releases. At the same time, I've also added an avx version for Linux. These have my standard dev fee structure - 2% default (1.5% to me, 0.25% jh00, 0.25% clintar), and you can increase or decrease it from the command line or in the source code as you wish.

Any chance to have the AVX2 version as well? Lips sealed

The version of mingw I have doesn't support avx2. Is there one that does? I'm happy to upgrade if it's ubuntu-friendly.

Supercomputing

sr. member

Activity: 278

Merit: 250

Quote from: madMAx510510 on April 01, 2014, 11:29:05 AM

Quote from: Supercomputing on March 26, 2014, 01:34:33 PM

asm( "add.cc.u32 %0, %0, %1;" : "+r"(r[0]) : "r"(tasm));
   asm( "madc.hi.u32 %0, %1, %2, 0;" : "=r"(tasm) : "r"(op1[0*op1_interleaved]), "r"(op2[0*op2_interleaved]));
   asm( "mad.lo.cc.u32 %0, %1, %2, %0;" : "+r"(r[0]) : "r"(op1[0*op1_interleaved]), "r"(op2[0*op2_interleaved]));
   asm( "addc.u32 %0, %0, 0;" : "+r"(tasm));
   asm( "add.cc.u32 %0, %0, %1;" : "+r"(r[1]) : "r"(tasm));
   asm( "madc.hi.u32 %0, %1, %2, 0;" : "=r"(tasm) : "r"(op1[1*op1_interleaved]), "r"(op2[0*op2_interleaved]));
   asm( "mad.lo.cc.u32 %0, %1, %2, %0;" : "+r"(r[1]) : "r"(op1[1*op1_interleaved]), "r"(op2[0*op2_interleaved]));
   asm( "addc.u32 %0, %0, 0;" : "+r"(tasm));
   asm( "add.cc.u32 %0, %0, %1;" : "+r"(r[2]) : "r"(tasm));
   asm( "madc.hi.u32 %0, %1, %2, 0;" : "=r"(tasm) : "r"(op1[2*op1_interleaved]), "r"(op2[0*op2_interleaved]));
   asm( "mad.lo.cc.u32 %0, %1, %2, %0;" : "+r"(r[2]) : "r"(op1[2*op1_interleaved]), "r"(op2[0*op2_interleaved]));
   asm( "addc.u32 %0, %0, 0;" : "+r"(tasm));
   asm( "add.cc.u32 %0, %0, %1;" : "+r"(r[3]) : "r"(tasm));
   asm( "madc.hi.u32 %0, %1, %2, 0;" : "=r"(tasm) : "r"(op1[3*op1_interleaved]), "r"(op2[0*op2_interleaved]));
   asm( "mad.lo.cc.u32 %0, %1, %2, %0;" : "+r"(r[3]) : "r"(op1[3*op1_interleaved]), "r"(op2[0*op2_interleaved]));
   asm( "addc.u32 %0, %0, 0;" : "+r"(tasm));
   asm( "add.cc.u32 %0, %0, %1;" : "+r"(r[4]) : "r"(tasm));
   asm( "madc.hi.u32 %0, %1, %2, 0;" : "=r"(tasm) : "r"(op1[4*op1_interleaved]), "r"(op2[0*op2_interleaved]));
   asm( "mad.lo.cc.u32 %0, %1, %2, %0;" : "+r"(r[4]) : "r"(op1[4*op1_interleaved]), "r"(op2[0*op2_interleaved]));
   asm( "addc.u32 %0, %0, 0;" : "+r"(tasm));
   asm( "add.cc.u32 %0, %0, %1;" : "+r"(r[5]) : "r"(tasm));
   asm( "madc.hi.u32 %0, %1, %2, 0;" : "=r"(tasm) : "r"(op1[5*op1_interleaved]), "r"(op2[0*op2_interleaved]));
   asm( "mad.lo.cc.u32 %0, %1, %2, %0;" : "+r"(r[5]) : "r"(op1[5*op1_interleaved]), "r"(op2[0*op2_interleaved]));
   asm( "addc.u32 %0, %0, 0;" : "+r"(tasm));
   asm( "add.cc.u32 %0, %0, %1;" : "+r"(r[6]) : "r"(tasm));
   asm( "madc.hi.u32 %0, %1, %2, 0;" : "=r"(tasm) : "r"(op1[6*op1_interleaved]), "r"(op2[0*op2_interleaved]));
   asm( "mad.lo.cc.u32 %0, %1, %2, %0;" : "+r"(r[6]) : "r"(op1[6*op1_interleaved]), "r"(op2[0*op2_interleaved]));
   asm( "addc.u32 %0, %0, 0;" : "+r"(tasm));
   asm( "add.cc.u32 %0, %0, %1;" : "+r"(r[7]) : "r"(tasm));
   asm( "madc.hi.u32 %0, %1, %2, 0;" : "=r"(tasm) : "r"(op1[7*op1_interleaved]), "r"(op2[0*op2_interleaved]));
   asm( "mad.lo.cc.u32 %0, %1, %2, %0;" : "+r"(r[7]) : "r"(op1[7*op1_interleaved]), "r"(op2[0*op2_interleaved]));
   asm( "addc.u32 %0, %0, 0;" : "+r"(tasm));
   asm( "add.cc.u32 %0, %0, %1;" : "+r"(r[8]) : "r"(tasm));
   asm( "madc.hi.u32 %0, %1, %2, 0;" : "=r"(tasm) : "r"(op1[8*op1_interleaved]), "r"(op2[0*op2_interleaved]));
   asm( "mad.lo.cc.u32 %0, %1, %2, %0;" : "+r"(r[8]) : "r"(op1[8*op1_interleaved]), "r"(op2[0*op2_interleaved]));
   asm( "addc.u32 %0, %0, 0;" : "+r"(tasm));
   asm( "add.cc.u32 %0, %0, %1;" : "+r"(r[9]) : "r"(tasm));
   asm( "madc.hi.u32 %0, %1, %2, 0;" : "=r"(tasm) : "r"(op1[9*op1_interleaved]), "r"(op2[0*op2_interleaved]));
   asm( "mad.lo.cc.u32 %0, %1, %2, %0;" : "+r"(r[9]) : "r"(op1[9*op1_interleaved]), "r"(op2[0*op2_interleaved]));
   asm( "addc.u32 %0, %0, 0;" : "+r"(tasm));
   asm( "add.cc.u32 %0, %0, %1;" : "+r"(c0) : "r"(tasm) );
   asm( "addc.u32 %0, 0, 0;" : "=r"(c1));

I don't get why you have so many adds in there... especially when you have fancy mad.lo.cc.u32/mad.hi.cc.u32 instructions...

You would be correct if I were performing just straight multiple-precision multiplication arithmetic per thread, but I am not. It is multiplication + reduction in one pass + fancy coalesced memory access.

toto408

newbie

Activity: 8

Merit: 0

Quote from: dga on April 01, 2014, 09:33:00 AM

Quote from: cphr on April 01, 2014, 01:45:07 AM

I've compiled custom build(windows 64bit) from jh00 xptminer and dga ric core with gmp 6.0.0(not mpir) and avx-i support (Ivy Bridge processors only).

Build include 1% devfee (hardcoded).

Don't you find it a little odd to rip out someone's existing dev fee when there's a mechanism in there to add your own to the stack and ensure that all of the developers continue to have an incentive to work on the software? I do. So:

There's now an official build for Windows 64bit against gmp 6.0.0a with avx support at:

http://www.cs.cmu.edu/~dga/crypto/ric/

Along with the existing sse4 version. I've automated the build for this platform and will continue to maintain it through future releases. At the same time, I've also added an avx version for Linux. These have my standard dev fee structure - 2% default (1.5% to me, 0.25% jh00, 0.25% clintar), and you can increase or decrease it from the command line or in the source code as you wish.

Any chance to have the AVX2 version as well? Lips sealed

northranger79510

sr. member

Activity: 308

Merit: 250

Riecoin and Huntercoin to rule all!

Multi-Sigs have been verified that it works and foundation will be open for donations later today.

madMAx510510

member

Activity: 70

Merit: 10

Quote from: Supercomputing on March 26, 2014, 01:34:33 PM

asm( "add.cc.u32 %0, %0, %1;" : "+r"(r[0]) : "r"(tasm));
   asm( "madc.hi.u32 %0, %1, %2, 0;" : "=r"(tasm) : "r"(op1[0*op1_interleaved]), "r"(op2[0*op2_interleaved]));
   asm( "mad.lo.cc.u32 %0, %1, %2, %0;" : "+r"(r[0]) : "r"(op1[0*op1_interleaved]), "r"(op2[0*op2_interleaved]));
   asm( "addc.u32 %0, %0, 0;" : "+r"(tasm));
   asm( "add.cc.u32 %0, %0, %1;" : "+r"(r[1]) : "r"(tasm));
   asm( "madc.hi.u32 %0, %1, %2, 0;" : "=r"(tasm) : "r"(op1[1*op1_interleaved]), "r"(op2[0*op2_interleaved]));
   asm( "mad.lo.cc.u32 %0, %1, %2, %0;" : "+r"(r[1]) : "r"(op1[1*op1_interleaved]), "r"(op2[0*op2_interleaved]));
   asm( "addc.u32 %0, %0, 0;" : "+r"(tasm));
   asm( "add.cc.u32 %0, %0, %1;" : "+r"(r[2]) : "r"(tasm));
   asm( "madc.hi.u32 %0, %1, %2, 0;" : "=r"(tasm) : "r"(op1[2*op1_interleaved]), "r"(op2[0*op2_interleaved]));
   asm( "mad.lo.cc.u32 %0, %1, %2, %0;" : "+r"(r[2]) : "r"(op1[2*op1_interleaved]), "r"(op2[0*op2_interleaved]));
   asm( "addc.u32 %0, %0, 0;" : "+r"(tasm));
   asm( "add.cc.u32 %0, %0, %1;" : "+r"(r[3]) : "r"(tasm));
   asm( "madc.hi.u32 %0, %1, %2, 0;" : "=r"(tasm) : "r"(op1[3*op1_interleaved]), "r"(op2[0*op2_interleaved]));
   asm( "mad.lo.cc.u32 %0, %1, %2, %0;" : "+r"(r[3]) : "r"(op1[3*op1_interleaved]), "r"(op2[0*op2_interleaved]));
   asm( "addc.u32 %0, %0, 0;" : "+r"(tasm));
   asm( "add.cc.u32 %0, %0, %1;" : "+r"(r[4]) : "r"(tasm));
   asm( "madc.hi.u32 %0, %1, %2, 0;" : "=r"(tasm) : "r"(op1[4*op1_interleaved]), "r"(op2[0*op2_interleaved]));
   asm( "mad.lo.cc.u32 %0, %1, %2, %0;" : "+r"(r[4]) : "r"(op1[4*op1_interleaved]), "r"(op2[0*op2_interleaved]));
   asm( "addc.u32 %0, %0, 0;" : "+r"(tasm));
   asm( "add.cc.u32 %0, %0, %1;" : "+r"(r[5]) : "r"(tasm));
   asm( "madc.hi.u32 %0, %1, %2, 0;" : "=r"(tasm) : "r"(op1[5*op1_interleaved]), "r"(op2[0*op2_interleaved]));
   asm( "mad.lo.cc.u32 %0, %1, %2, %0;" : "+r"(r[5]) : "r"(op1[5*op1_interleaved]), "r"(op2[0*op2_interleaved]));
   asm( "addc.u32 %0, %0, 0;" : "+r"(tasm));
   asm( "add.cc.u32 %0, %0, %1;" : "+r"(r[6]) : "r"(tasm));
   asm( "madc.hi.u32 %0, %1, %2, 0;" : "=r"(tasm) : "r"(op1[6*op1_interleaved]), "r"(op2[0*op2_interleaved]));
   asm( "mad.lo.cc.u32 %0, %1, %2, %0;" : "+r"(r[6]) : "r"(op1[6*op1_interleaved]), "r"(op2[0*op2_interleaved]));
   asm( "addc.u32 %0, %0, 0;" : "+r"(tasm));
   asm( "add.cc.u32 %0, %0, %1;" : "+r"(r[7]) : "r"(tasm));
   asm( "madc.hi.u32 %0, %1, %2, 0;" : "=r"(tasm) : "r"(op1[7*op1_interleaved]), "r"(op2[0*op2_interleaved]));
   asm( "mad.lo.cc.u32 %0, %1, %2, %0;" : "+r"(r[7]) : "r"(op1[7*op1_interleaved]), "r"(op2[0*op2_interleaved]));
   asm( "addc.u32 %0, %0, 0;" : "+r"(tasm));
   asm( "add.cc.u32 %0, %0, %1;" : "+r"(r[8]) : "r"(tasm));
   asm( "madc.hi.u32 %0, %1, %2, 0;" : "=r"(tasm) : "r"(op1[8*op1_interleaved]), "r"(op2[0*op2_interleaved]));
   asm( "mad.lo.cc.u32 %0, %1, %2, %0;" : "+r"(r[8]) : "r"(op1[8*op1_interleaved]), "r"(op2[0*op2_interleaved]));
   asm( "addc.u32 %0, %0, 0;" : "+r"(tasm));
   asm( "add.cc.u32 %0, %0, %1;" : "+r"(r[9]) : "r"(tasm));
   asm( "madc.hi.u32 %0, %1, %2, 0;" : "=r"(tasm) : "r"(op1[9*op1_interleaved]), "r"(op2[0*op2_interleaved]));
   asm( "mad.lo.cc.u32 %0, %1, %2, %0;" : "+r"(r[9]) : "r"(op1[9*op1_interleaved]), "r"(op2[0*op2_interleaved]));
   asm( "addc.u32 %0, %0, 0;" : "+r"(tasm));
   asm( "add.cc.u32 %0, %0, %1;" : "+r"(c0) : "r"(tasm) );
   asm( "addc.u32 %0, 0, 0;" : "=r"(c1));

I don't get why you have so many adds in there... especially when you have fancy mad.lo.cc.u32/mad.hi.cc.u32 instructions...

primer10

sr. member

Activity: 249

Merit: 250

Just wanna thank gatra, dga and not forgetting jh00 and clintar.

Waiting for the day world record is broken Grin

antonio8

legendary

Activity: 1400

Merit: 1000

@dga

Thanks for the Windows version of avx miner and also for the work you do.

dga

hero member

Activity: 737

Merit: 511

Quote from: cphr on April 01, 2014, 01:45:07 AM

I've compiled custom build(windows 64bit) from jh00 xptminer and dga ric core with gmp 6.0.0(not mpir) and avx-i support (Ivy Bridge processors only).

Build include 1% devfee (hardcoded).

Don't you find it a little odd to rip out someone's existing dev fee when there's a mechanism in there to add your own to the stack and ensure that all of the developers continue to have an incentive to work on the software? I do. So:

There's now an official build for Windows 64bit against gmp 6.0.0a with avx support at:

http://www.cs.cmu.edu/~dga/crypto/ric/

Along with the existing sse4 version. I've automated the build for this platform and will continue to maintain it through future releases. At the same time, I've also added an avx version for Linux. These have my standard dev fee structure - 2% default (1.5% to me, 0.25% jh00, 0.25% clintar), and you can increase or decrease it from the command line or in the source code as you wish.

cphr, I'd love to talk about a strategy that has the right incentives for everyone. Just like I think it's great for pools to provide a dev fee mechanism to encourage miner innovation, I think it's important for devs and port maintainers to figure out a reasonable standard of expectation for how to split dev fees in a good way. Good outcomes would seem to include:
- Original developers have an incentive to keep developing and improving their software;
- Original developers want to make it easy for platform-porters to do their ports and keep in sync with the dev version;
- Platform-porters want to make awesome platform ports and receive a fair fee for doing so.

Any thoughts on the right way to do this in the future?

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

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