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

toptek

legendary

Activity: 1274

Merit: 1000

Quote from: niko2004x on November 30, 2016, 01:43:33 PM

Quote from: zawawa on November 30, 2016, 12:20:45 PM

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?

There is al ways that chance with any algorithm , but i don't think he means bad by potential repercussions.

niko2004x

member

Activity: 126

Merit: 10

Quote from: zawawa on November 30, 2016, 12:20:45 PM

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?

zawawa

sr. member

Activity: 728

Merit: 304

Miner Developer

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

laik2

sr. member

Activity: 652

Merit: 266

We need open source solution fast. Damn suckers will do anything to gain credit on behalf of someone else's work.
-->
https://bitcointalksearch.org/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.

SunStruck

sr. member

Activity: 676

Merit: 250

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

laik2

sr. member

Activity: 652

Merit: 266

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

sr. member

Activity: 676

Merit: 250

Rooting for you , my nvidia is kinda cold lately

zawawa

sr. member

Activity: 728

Merit: 304

Miner Developer

Quote from: nerdralph on November 28, 2016, 05:43:35 PM

Quote from: zawawa on November 28, 2016, 05:09:38 PM

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.

cryptomined

full member

Activity: 168

Merit: 104

Quote from: laik2 on November 28, 2016, 05:45:26 PM

Quote from: cryptomined on November 28, 2016, 05:39:12 PM

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 Tongue

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

laik2

sr. member

Activity: 652

Merit: 266

Quote from: cryptomined on November 28, 2016, 05:39:12 PM

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 Tongue

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"

nerdralph

sr. member

Activity: 588

Merit: 251

Quote from: zawawa on November 28, 2016, 05:09:38 PM

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.

cryptomined

full member

Activity: 168

Merit: 104

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 Tongue

pump it up!

nerdralph

sr. member

Activity: 588

Merit: 251

Quote from: zawawa on November 28, 2016, 05:09:38 PM

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

ioglnx

sr. member

Activity: 574

Merit: 250

Fighting mob law and inquisition in this forum

Quote from: zawawa on November 28, 2016, 05:09:38 PM

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

zawawa

sr. member

Activity: 728

Merit: 304

Miner Developer

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.

laik2

sr. member

Activity: 652

Merit: 266

Quote from: xeridea on November 28, 2016, 02:43:57 PM

Quote from: Subw on November 28, 2016, 12:57:11 PM

Quote from: xeridea on November 28, 2016, 12:27:31 PM

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

Quote from: xeridea on November 28, 2016, 12:27:31 PM

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

Quote from: xeridea on November 28, 2016, 12:27:31 PM

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

Quote from: xeridea on November 28, 2016, 12:27:31 PM

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.

xeridea

sr. member

Activity: 449

Merit: 251

Quote from: Subw on November 28, 2016, 12:57:11 PM

Quote from: xeridea on November 28, 2016, 12:27:31 PM

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

Quote from: xeridea on November 28, 2016, 12:27:31 PM

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

Quote from: xeridea on November 28, 2016, 12:27:31 PM

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

Quote from: xeridea on November 28, 2016, 12:27:31 PM

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.

Subw

hero member

Activity: 672

Merit: 500

Quote from: xeridea on November 28, 2016, 12:27:31 PM

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

Quote from: xeridea on November 28, 2016, 12:27:31 PM

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

Quote from: xeridea on November 28, 2016, 12:27:31 PM

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

Quote from: xeridea on November 28, 2016, 12:27:31 PM

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

ghostfaceuk

sr. member

Activity: 410

Merit: 250

Quote from: xeridea on November 28, 2016, 12:23:30 PM

Quote from: ghostfaceuk on November 28, 2016, 11:17:49 AM

Quote from: xeridea on November 28, 2016, 10:37:00 AM

Quote from: Subw on November 28, 2016, 08:59:58 AM

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.

xeridea

sr. member

Activity: 449

Merit: 251

Quote from: Subw on November 28, 2016, 12:20:59 PM

Quote from: xeridea on November 28, 2016, 10:37:00 AM

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.

Topic: SILENTARMY v5: Zcash miner, 115 sol/s on R9 Nano, 70 sol/s on GTX 1070 - page 15. (Read 209334 times)