SILENTARMY v5: Zcash miner, 115 sol/s on R9 Nano, 70 sol/s on GTX 1070

[Hotmetal]

Here are some stats for my fork.

What is the url to your fork?

[cryptomined]

By the way, I found out the root cause of a low number of shares.
It turned out that there is a bug in AMD's drivers, so you need to so specify the "-O1" build option to disable most of optimizations when you call clBuildProgram if the miner is running on AMD cards. The optimizer must have incorrectly eliminated s_waitcnt. What a wonderful world.

is your fork ready for release?  thanks

[kay5ive]

By the way, I found out the root cause of a low number of shares.
It turned out that there is a bug in AMD's drivers, so you need to so specify the "-O1" build option to disable most of optimizations when you call clBuildProgram if the miner is running on AMD cards. The optimizer must have incorrectly eliminated s_waitcnt. What a wonderful world.

How to fork this? Do you have a method?
If you want to share with us?

[nerdralph]

I'm now using NR_ROWS_LOG=16 as the new sorting algorithm I implemented seems to prefer a larger NR_SLOTS.
I'm trying to set up NR_ROWS_LOG=14 and 15 to see how that would affect performance.

I think 14 will be close to ideal.  I expect 256 for NR_SLOTS will be enough to avoid row overflows, and that still allow using 1 byte for the row counters.  That's 16KB * 2 for the row counters, or only 32KB.

[Golku]

I'm now using NR_ROWS_LOG=16 as the new sorting algorithm I implemented seems to prefer a larger NR_SLOTS.
I'm trying to set up NR_ROWS_LOG=14 and 15 to see how that would affect performance.

I think 14 will be close to ideal.  I expect 256 for NR_SLOTS will be enough to avoid row overflows, and that still allow using 1 byte for the row counters.  That's 16KB * 2 for the row counters, or only 32KB.

I got a feeling that this miner will beat up claymores

[laik2]

I'm now using NR_ROWS_LOG=16 as the new sorting algorithm I implemented seems to prefer a larger NR_SLOTS.
I'm trying to set up NR_ROWS_LOG=14 and 15 to see how that would affect performance.

I think 14 will be close to ideal.  I expect 256 for NR_SLOTS will be enough to avoid row overflows, and that still allow using 1 byte for the row counters.  That's 16KB * 2 for the row counters, or only 32KB.

What happened to your closed source miner?

[Tatalk]

I'm now using NR_ROWS_LOG=16 as the new sorting algorithm I implemented seems to prefer a larger NR_SLOTS.
I'm trying to set up NR_ROWS_LOG=14 and 15 to see how that would affect performance.

I think 14 will be close to ideal.  I expect 256 for NR_SLOTS will be enough to avoid row overflows, and that still allow using 1 byte for the row counters.  That's 16KB * 2 for the row counters, or only 32KB.

I got a feeling that this miner will beat up claymores

I do not think the developers has much incentive to beat the Claymore. They are not rewarded properly.

[issie81]

I do not think the developers has much incentive to beat the Claymore. They are not rewarded properly.

why not implement 1% dev fee?

the linux miners are more stable

[doktor83]

I do not think the developers has much incentive to beat the Claymore. They are not rewarded properly.

why not implement 1% dev fee?

the linux miners are more stable

i don't have any stability problems with claymore's, and its not a linux miner.

[nerdralph]

I'm now using NR_ROWS_LOG=16 as the new sorting algorithm I implemented seems to prefer a larger NR_SLOTS.
I'm trying to set up NR_ROWS_LOG=14 and 15 to see how that would affect performance.

I think 14 will be close to ideal.  I expect 256 for NR_SLOTS will be enough to avoid row overflows, and that still allow using 1 byte for the row counters.  That's 16KB * 2 for the row counters, or only 32KB.

What happened to your closed source miner?

Perfection takes time. :-)  If you want to see the results of some of my research into memory performance, check this out:
https://github.com/nerdralph/cl-mem

[eXtremal]

Did anybody implement NR_ROWS less than 16 support already ?

[ioglnx]

Did anybody implement NR_ROWS less than 16 support already ?

Nope not yet..and welcome back :-D

[zawawa]

Did anybody implement NR_ROWS less than 16 support already ?

I was wondering about the same thing...
I'm almost done, but it's a major PITA to code.

[zawawa]

I'm now using NR_ROWS_LOG=16 as the new sorting algorithm I implemented seems to prefer a larger NR_SLOTS.
I'm trying to set up NR_ROWS_LOG=14 and 15 to see how that would affect performance.

I think 14 will be close to ideal.  I expect 256 for NR_SLOTS will be enough to avoid row overflows, and that still allow using 1 byte for the row counters.  That's 16KB * 2 for the row counters, or only 32KB.

I agree. This is a perfect reason to use a GCN assembler and squeeze two sets of 32KB rowCounters[] into 64KB GDS.
It is almost meant to be 

[Hotmetal]

I'm now using NR_ROWS_LOG=16 as the new sorting algorithm I implemented seems to prefer a larger NR_SLOTS.
I'm trying to set up NR_ROWS_LOG=14 and 15 to see how that would affect performance.

I think 14 will be close to ideal.  I expect 256 for NR_SLOTS will be enough to avoid row overflows, and that still allow using 1 byte for the row counters.  That's 16KB * 2 for the row counters, or only 32KB.

I agree. This is a perfect reason to use a GCN assembler and squeeze two sets of 32KB rowCounters[] into 64KB GDS.
It is almost meant to be 

Make it so

[zawawa]

I will, I will. No worries. I will release my fork in a day or two.
Although it is not as fast as Claymore's yet, it should be much faster than SA v5 on AMD cards.
I already sold most of my NVIDIA cards, so I have no idea how it would compare on NVIDIA cards.
If I had received a lot of donations, I could have justified purchasing GTX 1060 to my wife, but I could only dream...

[zzzzzzzzzz]

I will, I will. No worries. I will release my fork in a day or two.
Although it is not as fast as Claymore's yet, it should be much faster than SA v5 on AMD cards.
I already sold most of my NVIDIA cards, so I have no idea how it would compare on NVIDIA cards.
If I had received a lot of donations, I could have justified purchasing GTX 1060 to my wife, but I could only dream...

Thanks for your work! Just to clarify (for myself), your fork will be Windows-only, correct? I'm sure looking forward to looking at both your new code and Marc's, when they become available. It will be very interesting to see what approaches you each took on the algo/implementation. Don't let it interfere with your Holiday with the family, though! That's much higher priority! Best wishes ...

[Subw]

Although it is not as fast as Claymore's yet, it should be much faster than SA v5 on AMD cards.

how much fast?

I already sold most of my NVIDIA cards, so I have no idea how it would compare on NVIDIA cards.
If I had received a lot of donations, I could have justified purchasing GTX 1060 to my wife, but I could only dream...

will donate $50 for your GTX1060 fund

[Subw]

your fork will be Windows-only, correct?

i hope not at least i'm not gonna donate anything for windows only software

[zzzzzzzzzz]

your fork will be Windows-only, correct?

i hope not at least i'm not gonna donate anything for windows only software

Marc (alias mrb) is working on the linux SA v6 miner separately, so there will be an OSS linux miner update. Also, zawawa's will be OSS, so anyone can port it to linux, if they want.