What about the commit history on GitHub? It's on there, right?
Yep, exactly... that's why I had girino in my mind in the first place.
Topic: [ANN] SpreadCoin | Decentralize Everything (decentralized blockexplorer coming) - page 225. (Read 790391 times)
November 20, 2015, 07:07:10 PM
Yep, exactly... that's why I had girino in my mind in the first place.
November 20, 2015, 07:05:51 PM
Looks like I oopsed, they're not hashing the same thing over 3k times, they're hashing an INSANE amount of data. What the fuck is all of this...?
I don't remember who put together the AMD miner, I'm not even sure if I was part of spreadcoin community yet back then.
Looks like whoever did this was pretty negligent.
But didn't someone else (girino?) create an "improved" version after that?
hm.... need to check the old thread's history.
November 19, 2015, 11:20:32 AM
Its just a shame I am AMD
Just a quick note for anybody updating to Windows 10 (and associated latest AMD drivers). On Windows 8.1 I was able to download the SpreadX11 miner and mine away reasonably happy without an sgminer.conf file. On Windows 10 this will not work as sgminer will not take your card out of power saving mode leading to very low hashrates (slower than CPU mining!). It is easy to fix...you just need to create an sgminer.conf for your AMD card with appropriate parameters to force the AMD drivers to wake themselves up from power saving mode.
I just googled for a .conf file for X11 for my card and those parameters worked fine for me.
Just a quick note for anybody updating to Windows 10 (and associated latest AMD drivers). On Windows 8.1 I was able to download the SpreadX11 miner and mine away reasonably happy without an sgminer.conf file. On Windows 10 this will not work as sgminer will not take your card out of power saving mode leading to very low hashrates (slower than CPU mining!). It is easy to fix...you just need to create an sgminer.conf for your AMD card with appropriate parameters to force the AMD drivers to wake themselves up from power saving mode.
I just googled for a .conf file for X11 for my card and those parameters worked fine for me.
What hashrates are you getting?
Hi!
About 1.2M with an AMD R9 270
I get a *lot* more than that with your optimised X11 miner with the same card
Yeah, but you also do a SHITTON of stupid sha256 hashes that aren't done in X11 with SpreadX11.
Being generally clueless, I had the good fortune to be on Slack when georgem unravelled what was going on with SPRX11. I like what it stands for but I hate how inefficient it is.
Why over 3000 SHA256 hashes were used, I'll never know.
We may never find out. Something to be addressed one day. Inefficiency by design is inexcusable. Roll on X11 ASICS
Where's the Slack?
November 20, 2015, 07:02:44 PM
Looks like I oopsed, they're not hashing the same thing over 3k times, they're hashing an INSANE amount of data. What the fuck is all of this...?
I don't remember who put together the AMD miner, I'm not even sure if I was part of spreadcoin community yet back then.
Looks like whoever did this was pretty negligent.
But didn't someone else (girino?) create an "improved" version after that?
hm.... need to check the old thread's history.
November 20, 2015, 06:54:42 PM
Looks like I oopsed, they're not hashing the same thing over 3k times, they're hashing an INSANE amount of data. What the fuck is all of this...?
I don't remember who put together the AMD miner, I'm not even sure if I was part of spreadcoin community yet back then.
Looks like whoever did this was pretty negligent.
November 19, 2015, 11:10:11 AM
Its just a shame I am AMD
Just a quick note for anybody updating to Windows 10 (and associated latest AMD drivers). On Windows 8.1 I was able to download the SpreadX11 miner and mine away reasonably happy without an sgminer.conf file. On Windows 10 this will not work as sgminer will not take your card out of power saving mode leading to very low hashrates (slower than CPU mining!). It is easy to fix...you just need to create an sgminer.conf for your AMD card with appropriate parameters to force the AMD drivers to wake themselves up from power saving mode.
I just googled for a .conf file for X11 for my card and those parameters worked fine for me.
Just a quick note for anybody updating to Windows 10 (and associated latest AMD drivers). On Windows 8.1 I was able to download the SpreadX11 miner and mine away reasonably happy without an sgminer.conf file. On Windows 10 this will not work as sgminer will not take your card out of power saving mode leading to very low hashrates (slower than CPU mining!). It is easy to fix...you just need to create an sgminer.conf for your AMD card with appropriate parameters to force the AMD drivers to wake themselves up from power saving mode.
I just googled for a .conf file for X11 for my card and those parameters worked fine for me.
What hashrates are you getting?
Hi!
About 1.2M with an AMD R9 270
I get a *lot* more than that with your optimised X11 miner with the same card
Yeah, but you also do a SHITTON of stupid sha256 hashes that aren't done in X11 with SpreadX11.
Being generally clueless, I had the good fortune to be on Slack when georgem unravelled what was going on with SPRX11. I like what it stands for but I hate how inefficient it is.
Why over 3000 SHA256 hashes were used, I'll never know. What's the URL for Slack?
November 20, 2015, 05:57:53 PM
Looks like I oopsed, they're not hashing the same thing over 3k times, they're hashing an INSANE amount of data. What the fuck is all of this...?
I don't remember who put together the AMD miner, I'm not even sure if I was part of spreadcoin community yet back then.
Looks like whoever did this was pretty negligent.
November 19, 2015, 02:54:17 PM
If you know C, you should already be able to see how ridiculous most of the code is. Echo is really bad.
I'm fighting with priorities on a daily basis, but I'll take a look at it soon.
You talking about both the AMD and NVidia version here?
They were created by different people as far as I know.
November 19, 2015, 11:04:56 AM
Its just a shame I am AMD
Just a quick note for anybody updating to Windows 10 (and associated latest AMD drivers). On Windows 8.1 I was able to download the SpreadX11 miner and mine away reasonably happy without an sgminer.conf file. On Windows 10 this will not work as sgminer will not take your card out of power saving mode leading to very low hashrates (slower than CPU mining!). It is easy to fix...you just need to create an sgminer.conf for your AMD card with appropriate parameters to force the AMD drivers to wake themselves up from power saving mode.
I just googled for a .conf file for X11 for my card and those parameters worked fine for me.
Just a quick note for anybody updating to Windows 10 (and associated latest AMD drivers). On Windows 8.1 I was able to download the SpreadX11 miner and mine away reasonably happy without an sgminer.conf file. On Windows 10 this will not work as sgminer will not take your card out of power saving mode leading to very low hashrates (slower than CPU mining!). It is easy to fix...you just need to create an sgminer.conf for your AMD card with appropriate parameters to force the AMD drivers to wake themselves up from power saving mode.
I just googled for a .conf file for X11 for my card and those parameters worked fine for me.
What hashrates are you getting?
Hi!
About 1.2M with an AMD R9 270
I get a *lot* more than that with your optimised X11 miner with the same card
Yeah, but you also do a SHITTON of stupid sha256 hashes that aren't done in X11 with SpreadX11.
November 19, 2015, 02:47:32 PM
No problem. The OpenCL is still slow, the current algorithm can be implemented a lot better, even if not changed.
Well, I don't think the current algorithm needs to be changed at the core,
except to get rid of inefficiencies or to make the "pool-prevention"-mechanism stronger (which is certainly necessary).
If you have any ideas, let us know!
More splitting of the kernels, replacing most of the X11 code. I think the AMD compiler will derp out of some kernels are seperated, but more can be without error.
One of these days, I'll need to dive into GPU/ OpenCL programming too... it giggity-geeks the hell out of me already, lol!
November 19, 2015, 02:40:55 PM
No problem. The OpenCL is still slow, the current algorithm can be implemented a lot better, even if not changed.
Well, I don't think the current algorithm needs to be changed at the core,
except to get rid of inefficiencies or to make the "pool-prevention"-mechanism stronger (which is certainly necessary).
If you have any ideas, let us know!
November 19, 2015, 02:35:22 PM
If it was an error, it wouldn't get the right hash. It's correct.
I meant to say "bug", not error, ofcourse.
Not a bug - if I change/remove it, wrong hashes.
well, if - as you say - it causes a horrible inefficiency, then it's a bug in my book.
Hey thanks, that you take your time to look into this BTW.
November 18, 2015, 06:14:56 PM
Its just a shame I am AMD
Just a quick note for anybody updating to Windows 10 (and associated latest AMD drivers). On Windows 8.1 I was able to download the SpreadX11 miner and mine away reasonably happy without an sgminer.conf file. On Windows 10 this will not work as sgminer will not take your card out of power saving mode leading to very low hashrates (slower than CPU mining!). It is easy to fix...you just need to create an sgminer.conf for your AMD card with appropriate parameters to force the AMD drivers to wake themselves up from power saving mode.
I just googled for a .conf file for X11 for my card and those parameters worked fine for me.
Just a quick note for anybody updating to Windows 10 (and associated latest AMD drivers). On Windows 8.1 I was able to download the SpreadX11 miner and mine away reasonably happy without an sgminer.conf file. On Windows 10 this will not work as sgminer will not take your card out of power saving mode leading to very low hashrates (slower than CPU mining!). It is easy to fix...you just need to create an sgminer.conf for your AMD card with appropriate parameters to force the AMD drivers to wake themselves up from power saving mode.
I just googled for a .conf file for X11 for my card and those parameters worked fine for me.
What hashrates are you getting?
November 19, 2015, 02:32:44 PM
If it was an error, it wouldn't get the right hash. It's correct.
I meant to say "bug", not error, ofcourse.
EDIT: BTW There is something peculiar in the in-wallet-miner where we are only applying the PoK-mechanism every 64 nonces:
https://github.com/spreadcoin/spreadcoin/blob/master/src/main.cpp#L1500
does it work the same in the openCL version?
November 19, 2015, 02:29:54 PM
Mining optimization meaning the current algo?
Wait, let's first further analyze this.
So you are saying we have about 3000 unnecessary SHA256 calculations per second, right?
On what GPU with what settings are you getting those values?
Not per second. PER HASH. I'm looking at the OpenCL code, it's right there.
ok, I'm only looking at the in-wallet CPU miner code, probably it's just an error in the OpenCL version?
Can you point me to the line in the sourcecode of the OpenCL version please.
November 19, 2015, 02:25:17 PM
Why over 3000 SHA256 hashes were used, I'll never know. What's the URL for Slack?
Yeah, I'm sure mr.spread's mining algo can be optimized.
The reason we use a little SHA256 in our algo is because the miner has to provide a hashWholeBlock value (to prove he himself had first knowledge about the block content, called POK "Proof Of Knowledge" in the sourcecode),
which ofcourse is derived thru a common double SHA256, and which has to be recalculated whenever ANYTHING in the block changes (timestamp, nonce (but only every 64 nonces), txs, etc...)
It's explained in mr. spread's whitepaper : http://www.spreadcoin.info/downloads/SpreadCoin-WhitePaper.pdf
(which admittedly is a little bit cryptic and not using the "clearest" english... I'm working on a more readable whitepaper version when servicenodes have progressed a little bit)
No, I know that. What I don't know is why you need 3000 goddamned iterations.
I'm not sure about that either.
Mr. Spread uses the hashPrevBlock (which is known and stays the same while we hash) to fill up the padding he's using to construct a complete MAX SIZE block which is then used to create the hashWholeBlock value.
So you probably assume that it would be enough if we derived the hashWholeBlock just once after a miner has found a solution (since hashWholeBlock is not part of the actual POW).
But I'm not sure if we are not missing something important here.
I wouldn't mind if a mining specialist like you takes a close look at it.
Nope. There is ZERO reason to hash the same data that many times. It's barbaric overkill.
Maybe a deliberately crippled miner? I don't like to suggest it but I can't see any other reason behind it.
November 19, 2015, 02:19:40 PM
Mining optimization meaning the current algo?
Yes, but wait, let's first further analyze this.
So you are saying we have about 3000 unnecessary SHA256 calculations per second, right?
On what GPU with what settings are you getting those values?
November 19, 2015, 02:05:58 PM
Why over 3000 SHA256 hashes were used, I'll never know. What's the URL for Slack?
Yeah, I'm sure mr.spread's mining algo can be optimized.
The reason we use a little SHA256 in our algo is because the miner has to provide a hashWholeBlock value (to prove he himself had first knowledge about the block content, called POK "Proof Of Knowledge" in the sourcecode),
which ofcourse is derived thru a common double SHA256, and which has to be recalculated whenever ANYTHING in the block changes (timestamp, nonce (but only every 64 nonces), txs, etc...)
It's explained in mr. spread's whitepaper : http://www.spreadcoin.info/downloads/SpreadCoin-WhitePaper.pdf
(which admittedly is a little bit cryptic and not using the "clearest" english... I'm working on a more readable whitepaper version when servicenodes have progressed a little bit)
No, I know that. What I don't know is why you need 3000 goddamned iterations.
I'm not sure about that either.
Mr. Spread uses the hashPrevBlock (which is known and stays the same while we hash) to fill up the padding he's using to construct a complete MAX SIZE block which is then used to create the hashWholeBlock value.
So you probably assume that it would be enough if we derived the hashWholeBlock just once after a miner has found a solution (since hashWholeBlock is not part of the actual POW).
But I'm not sure if we are not missing something important here.
I wouldn't mind if a mining specialist like you takes a close look at it.
Nope. There is ZERO reason to hash the same data that many times. It's barbaric overkill.
I'm currently occupied with servicenode development, and I was going to look into mining optimization only after that.
But if you want to give it a try and optimize the mining code, you are highly welcomed, and I'm sure the community is going to reward your efforts.
BTW, nobody doubts that mr. spread's code can be optimized. He left us in freaking mid-air.
November 19, 2015, 01:58:24 PM
Why over 3000 SHA256 hashes were used, I'll never know. What's the URL for Slack?
Yeah, I'm sure mr.spread's mining algo can be optimized.
The reason we use a little SHA256 in our algo is because the miner has to provide a hashWholeBlock value (to prove he himself had first knowledge about the block content, called POK "Proof Of Knowledge" in the sourcecode),
which ofcourse is derived thru a common double SHA256, and which has to be recalculated whenever ANYTHING in the block changes (timestamp, nonce (but only every 64 nonces), txs, etc...)
It's explained in mr. spread's whitepaper : http://www.spreadcoin.info/downloads/SpreadCoin-WhitePaper.pdf
(which admittedly is a little bit cryptic and not using the "clearest" english... I'm working on a more readable whitepaper version when servicenodes have progressed a little bit)
No, I know that. What I don't know is why you need 3000 goddamned iterations.
I'm not sure about that either.
Mr. Spread uses the hashPrevBlock (which is known and stays the same while we hash) to fill up the padding he's using to construct a complete MAX SIZE block which is then run thru doubleSHA256 to create the hashWholeBlock value.
So you probably assume that it would be enough if we derived the hashWholeBlock just once after a miner has found a solution (since hashWholeBlock is not part of the actual POW).
But I'm not sure if we are not missing something important here.
I wouldn't mind if a mining specialist like you takes a close look at it.
November 19, 2015, 01:32:56 PM
Why over 3000 SHA256 hashes were used, I'll never know. What's the URL for Slack?
Yeah, I'm sure mr.spread's mining algo can be optimized.
The reason we use a little SHA256 in our algo is because the miner has to provide a hashWholeBlock value (to prove he himself had first knowledge about the block content, called POK "Proof Of Knowledge" in the sourcecode https://github.com/spreadcoin/spreadcoin/blob/master/src/main.cpp#L1529 ),
which ofcourse is derived thru a common double SHA256, and which has to be recalculated whenever ANYTHING in the block changes (timestamp, nonce (but only every 64 nonces), txs, etc...)
It's explained in mr. spread's whitepaper : http://www.spreadcoin.info/downloads/SpreadCoin-WhitePaper.pdf
(which admittedly is a little bit cryptic and not using the "clearest" english... I'm working on a more readable whitepaper version when servicenodes have progressed a little bit)
Jump to: