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

[xeridea]

What's bad?? The less closed source devfee miners the better.
I will look into creating USB bootable PC router OS hacked to cut any devfees.

So you would rather have more closed source private miners?  Devfee miners are fine, with a reasonable devfee, and if they are stable, and have many features.  Optiminer was obviously just a quick thrown together cashgrab.

I never tried Optiminer but from what I heard it was very unstable especially at first and the 15%(?) dev fee certainly seemed to me to be a way for the designer to grab as much ZEC as they could as quickly as they could.

I understand that they were among one of the faster miners but a fee that high (if that figure is correct) was too high to me

Yeah I would never use Optiminer due to absurd devfee, and instability.  I am fine with 2.5% for fast, stable, feature rich miner though.

[1714647677]

1714647677

[1714647677]

1714647677

[1714647677]

1714647677

[xeridea]

So you would rather have more closed source private miners?

private miners do exist regardless of whether we have public closed source miners or not thus i do not see a problem here.

The issue is that if there are ONLY private miners, and open source miners, the general public is going to be at a disadvantage. The idea behind crypto is decentralization, so if private miners sold to big farms is the only profitable way to make money, decentralization is lost.  Devfee miners are a nice middleground where devs get compensated for work without selling out to farms, and everyone can have top notch miners. More speed to the masses also dissuades CPU botnets.

[ghostfaceuk]

What's bad?? The less closed source devfee miners the better.
I will look into creating USB bootable PC router OS hacked to cut any devfees.

So you would rather have more closed source private miners?  Devfee miners are fine, with a reasonable devfee, and if they are stable, and have many features.  Optiminer was obviously just a quick thrown together cashgrab.

I never tried Optiminer but from what I heard it was very unstable especially at first and the 15%(?) dev fee certainly seemed to me to be a way for the designer to grab as much ZEC as they could as quickly as they could.

I understand that they were among one of the faster miners but a fee that high (if that figure is correct) was too high to me

Yeah I would never use Optiminer due to absurd devfee, and instability.  I am fine with 2.5% for fast, stable, feature rich miner though.

2.5% percent for a miner devfee is a fair figure I would say, be it with Claymore's miner or if SilentArmy introduced one.  The coders have spent their time and effort to make the miners for those of us who do not have the skills/time to do it ourselves so they should be able compensated for their efforts.

[Subw]

The issue is that if there are ONLY private miners, and open source miners, the general public is going to be at a disadvantage.

well... we are not living in a perfect world. someone somewhere would always take advantage

The idea behind crypto is decentralization

i believe open source is essential part of crypto and closed source software is a potential threat.
e.g. claymore could potentially use his miner to attack a network

so if private miners sold to big farms is the only profitable way to make money, decentralization is lost.

imo decentralization is not crucial for shitcoins but don't worry there are always open source software to help your desire for decentralization

Devfee miners are a nice middleground where devs get compensated for work without selling out to farms, and everyone can have top notch miners. More speed to the masses also dissuades CPU botnets.

don't worry devfee miners would still exist

[xeridea]

The issue is that if there are ONLY private miners, and open source miners, the general public is going to be at a disadvantage.

well... we are not living in a perfect world. someone somewhere would always take advantage

The idea behind crypto is decentralization

i believe open source is essential part of crypto and closed source software is a potential threat.
e.g. claymore could potentially use his miner to attack a network

so if private miners sold to big farms is the only profitable way to make money, decentralization is lost.

imo decentralization is not crucial for shitcoins but don't worry there are always open source software to help your desire for decentralization

Devfee miners are a nice middleground where devs get compensated for work without selling out to farms, and everyone can have top notch miners. More speed to the masses also dissuades CPU botnets.

don't worry devfee miners would still exist

Devfee miners make it so private miner devs can't really make much, since quality/speed of public miners is top notch.

If Claymore changed miner to behave maliciously, people would quickly realize it, and call him out, so there would not be sufficient users to attack the network.  Also he would lose credibility, and no one would use his miners, so he has little reason to do so. Edit... He could have malicious code that ran only after say a week, but he makes enough from fees, he wouldn't have a reason to do so.  This could also happen with private miners, and even open source (though it would be significantly harder to pull off).

Open source is also a very good boost, and with good devfee miner, open source is incentivised to match speed, so theoretically open source could then be as fast as what is possible with private miner.

ZEC isn't a garbage coin, so decentralization is crucial.  The founders wanted good miners for everyone, hence the contest. SA is a decent miner, just been behind, but it will catch up in time.

[laik2]

The issue is that if there are ONLY private miners, and open source miners, the general public is going to be at a disadvantage.

well... we are not living in a perfect world. someone somewhere would always take advantage

The idea behind crypto is decentralization

i believe open source is essential part of crypto and closed source software is a potential threat.
e.g. claymore could potentially use his miner to attack a network

so if private miners sold to big farms is the only profitable way to make money, decentralization is lost.

imo decentralization is not crucial for shitcoins but don't worry there are always open source software to help your desire for decentralization

Devfee miners are a nice middleground where devs get compensated for work without selling out to farms, and everyone can have top notch miners. More speed to the masses also dissuades CPU botnets.

don't worry devfee miners would still exist

Devfee miners make it so private miner devs can't really make much, since quality/speed of public miners is top notch.

If Claymore changed miner to behave maliciously, people would quickly realize it, and call him out, so there would not be sufficient users to attack the network.  Also he would lose credibility, and no one would use his miners, so he has little reason to do so. Edit... He could have malicious code that ran only after say a week, but he makes enough from fees, he wouldn't have a reason to do so.  This could also happen with private miners, and even open source (though it would be significantly harder to pull off).

Open source is also a very good boost, and with good devfee miner, open source is incentivised to match speed, so theoretically open source could then be as fast as what is possible with private miner.

ZEC isn't a garbage coin, so decentralization is crucial.  The founders wanted good miners for everyone, hence the contest. SA is a decent miner, just been behind, but it will catch up in time.

It could if interest for development involves real money
Otherwise...just use CM/OM and enjoy the silence here.

[zawawa]

Alright peeps, I'm getting some speedups, but I can go for more.
I've already made a ridiculous amount of changes to the basic data structures of SA.
Now each round has its own table, and the size of slots is optimized for each round.
(You don't actually need 32 bytes at later rounds.)
However, I think I must take things a step further.
Managing 2^18 global atomic counters simultaneously just doesn't seem like the most efficient way to me.
So please be patient. I really want to get this right.

[ioglnx]

Alright peeps, I'm getting some speedups, but I can go for more.
I've already made a ridiculous amount of changes to the basic data structures of SA.
Now each round has its own table, and the size of slots is optimized for each round.
(You don't actually need 32 bytes at later rounds.)
However, I think I must take things a step further.
Managing 2^18 global atomic counters simultaneously just doesn't seem like the most efficient way to me.
So please be patient. I really want to get this right.

Maybe you can post some figures..or numbers..something for the time between the between time

[nerdralph]

Now each round has its own table, and the size of slots is optimized for each round.
(You don't actually need 32 bytes at later rounds.)
However, I think I must take things a step further.
Managing 2^18 global atomic counters simultaneously just doesn't seem like the most efficient way to me.

Smaller data structures for the later rounds shouldn't make any performance improvement.  In fact I think writing a full 32 bytes at a time could be faster than writing only 16 bytes.
2^18 counters takes up 256KB which can easily fit in the L2 cache.  Keeping the slot reads and writes from polluting the cache should have a much bigger impact than reducing the counter table size.
I've played a bit with volatile pointers in ht_store, and they seem to impact performance, but I haven't done enough testing yet to say what exactly is going on.  I also want to play with mem_fence().  The OpenCL docs don't say anything about cache effects, but the AMD IL spec says this about fence_memory (pg 170):
"all memory export instructions are complete (the data has been written to physical memory, not in the cache) and is visible to other work-items."
http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/10/AMD_Intermediate_Language_%28IL%29_Specification_v2.pdf

[cryptomined]

I just tried to install silent army but when i ran ./silentarmy -- list i got some CL error
downloaed nerdralphs old fork and it worked fine

any idea why the current official silentarm is  giving that error?

zawawa, we cant wait, thanks for working on this pump it up!

[nerdralph]

Managing 2^18 global atomic counters simultaneously just doesn't seem like the most efficient way to me.

I was thinking 2^18 isn't a bad size for equihash_round either.  24 slots * 32 bytes = 768 bytes.  A 64-way kernel could copy the slot data to LDS 64-bytes at a time.  Instead of an exhaustive collision search, a quick bin sort could be done using 4 atomic counters in local memory.  I think ht_store would be best as a 8-way function, with separate threads writing a uint each.

Assuming the L2 cache pollution problem can be solved, such a kernel should be up to 50% faster than Optiminer.

[laik2]

I just tried to install silent army but when i ran ./silentarmy -- list i got some CL error
downloaed nerdralphs old fork and it worked fine

any idea why the current official silentarm is  giving that error?

zawawa, we cant wait, thanks for working on this pump it up!

try
 make OPENCL_HEADERS=/usr/include LIBOPENCL=/usr/lib/x86_64-linux  
should work...else if nvidia
 make OPENCL_HEADERS=/usr/local/cuda/include LIBOPENCL="/usr/local/cuda/lib64"

[cryptomined]

I just tried to install silent army but when i ran ./silentarmy -- list i got some CL error
downloaed nerdralphs old fork and it worked fine

any idea why the current official silentarm is  giving that error?

zawawa, we cant wait, thanks for working on this pump it up!

try
 make OPENCL_HEADERS=/usr/include LIBOPENCL=/usr/lib/x86_64-linux  
should work...else if nvidia
 make OPENCL_HEADERS=/usr/local/cuda/include LIBOPENCL="/usr/local/cuda/lib64"

yeah its an AMD rig, ok thanks, ill try that later today when i get back

[zawawa]

Managing 2^18 global atomic counters simultaneously just doesn't seem like the most efficient way to me.

I was thinking 2^18 isn't a bad size for equihash_round either.  24 slots * 32 bytes = 768 bytes.  A 64-way kernel could copy the slot data to LDS 64-bytes at a time.  Instead of an exhaustive collision search, a quick bin sort could be done using 4 atomic counters in local memory.  I think ht_store would be best as a 8-way function, with separate threads writing a uint each.

Assuming the L2 cache pollution problem can be solved, such a kernel should be up to 50% faster than Optiminer.

You know what, now I'm thinking there might be something fundamentally limiting about the way SA splits up the whole problem across work groups. They shouldn't be interacting with each other so frequently. They should be relatively independent from each other once the kernel is up and running. I am trying to implement a new way to parallelize Equihash. We will see.

[SunStruck]

Rooting for you , my nvidia is kinda cold lately

[laik2]

Well...there's been a few days only. Just wait
My cards are pretty hot...due to CM usage.
http://gpuz.techpowerup.com/16/11/29/sww.png
Undervolted, underclocked 180S/s....still eats a lot of power...that CM....SA only took 50W per gpu stable.(not from the wall)

[SunStruck]

Yea wasnt meant to put pressure or anything , just happy to see that there is still love for nvidia fellas

[laik2]

We need open source solution fast. Damn suckers will do anything to gain credit on behalf of someone else's work.
-->
https://bitcointalk.org/index.php?topic=1698828
@zawawa, can you share any preliminary version?

Look here: https://github.com/genesismining/sgminer-gm
They've put zcash silentarmy kernel on their roadmap. Good news for honest miners. Lets hope and wait.

[zawawa]

I'm working right on it right now, so no worries.
I am seeing VERY interesting things with huge potential repercussions.

[niko2004x]

potential repercussions

Do not like the sound of this words.
So is there a chance that some major parts of equihash can be shifted to fpga/asic for speed up?