ZCash GPU mining faster than CPU mining?

I’m not sure I understand. Ok so it costs a lot more electricity per hash than ethereum, but the only metric that matters is how much more electricity equihash gpu mining costs compared to equihash cpu mining. How much more expensive is it to go gpu mining at 10x efficiency compared to cup mining, and what are the relevant benchmarks and calculations that factor into this?

I have emphasized in previous posts that parallelizing the code to make use of the numerous GPU cores will come at a > 2x electricity cost. But I’ve just realized GPUs do not need the special algorithm to get 8x more than CPUs without any electrical efficiency loss (still $1.50 per coin for 50,000 CPU equivalents, aka 6,000 GPUs). The arguments are straightforward to conclude that GPUs should be 20x better despite my comments above (2.5x more threads because a GPU can have 10 cores working on 10 blocks in 8 GB on-board RAM at 8x bandwidth, so 2.5 x 8 = 20). My own experiments on the testnet with CPUs at lower clock speeds are what bring my estimate down to 8x since GPUs are 1/2 to 1/3 CPU clock speeds with I believe is less advanced caching. Zcash should have chosen 1.2 GB instead of 750 MB because you can’t run even a non-GUI linux with Zcash’s current parameters on 4 GB. 6 GB made things worse. It has to be 8 GB. Given that you have to use 8 GB and you want to block GPUs, it should have been 1.2 GB instead of 750 MB.

Ok so what you are saying is that it should cost $1.50 per coin whether or not you use GPUs or CPUs, but you will get like 20x more coins. Right?

I’m going to have to look over your posts again regarding the electricity cost equivalency, but feel free to link me to any other resources / statements in the equihash paper suggesting this electric cost equivalency.

For the benefit of anyone else reading this that may not be aware, this thread has become highly speculative. Many assumptions, very few facts.

I think you were the one who made me rethink things when you mentioned that the Equihash GPU reference was 2011. I previously noticed that but dismissed it because they were comparing to a 2011 CPU and I thought it would balance out again in today’s GPU’s vs CPUs, but that was faulty reasoning. So I went to see what the on-board RAM of today’s GPU is and saw a problem.

Concerning electricity usage, I am talking about a 50 W CPU as the reference. From there it is math: 1/240 hours per coin x 50,000 CPUs x 50 W each x 1/1000 kW/W x 0.14 $/kWh = $1.46 / coin. Note this does not depend on the coin other than the coins per hour. It’s more relevant here than in other coins because I believe GPUs and ASICs will not have an electricity advantage in Zcash like in other coins. So it’s $1.46 electrical cost to everyone, making it a more democratic coin. If they do not use parallel coding, GPUs might be 2x more efficient.

If you point out one of my comments you think is speculative, maybe I can back it up with references.

There is no reference for what a zec will sell for.

I was trying to say 20x more is the max. 8x more is my guess, in line with what others in this thread have said.

Note that Ethash was, contrary to some of the comments above, specifically designed to target GPUs: Ethash Design Rationale · ethereum/wiki Wiki · GitHub . So extrapolation from Ethash to Equihash on this point is not valid. Equihash attempts to reduce any efficiency gap between GPUs and CPUs; the extent to which it succeeds in doing that isn’t fully known yet.

[Edit: @waterhole already pointed this out; sorry I missed that comment.]

There is some discussion of GPU vs CPU efficiency in section VI of the Equihash paper.

There were some constraints on which parameters we could choose: in particular, the constraint that N be a multiple of both 8 and K+1, and the problem with latency of an Equihash solution run being too high compared to the block target time in releases before z8. Increasing the memory target also tends to increase this latency. We removed the constraint that N/(K+1) must be a multiple of 8 which allowed using the N=200, K=9 parameters, but removing the other constraint on N would have taken additional development time and delayed the launch, which I don’t think would have been a good engineering/project management/business decision.

1 Like

By the way, are you aware that the reason why Ethereum targets GPUs is that it explicitly acknowledges that it is “almost certainly impossible” to target for CPU mining? From eth github:

We try to make it as easy as possible to mine with GPUs. Targeting CPUs is almost certainly impossible, as potential specialization gains are too great, and there do exist criticisms of CPU-friendly algorithms that they are vulnerable to botnets, so we target GPUs as a compromise.

So basically Equihash is claiming that Ethereum’s statement is false, and not only false to a trivial extent but false to a significant extent.

cpu miner is good enought

If you would bother to read the Equihash whitepaper instead of expecting others to spoonfeed predigested insights to you, you would know that Equihash has been tested on GPUs from the outset. Therefore, no one (least of all a sorting algorithm…) is claiming that Equihash is CPU specific.

https://www.internetsociety.org/sites/default/files/blogs-media/equihash-asymmetric-proof-of-work-based-generalized-birthday-problem.pdf

Thanks, that’s what I did not know.

1 Like

There is an obvious diverging point of view about CPU viability from the people who developed Etherium and those that invented Equihash. It would certainly be an interesting debate for the two teams to have with each other but I think it is beyond the scope of finding a definitive answer in this forum.

Secondly, there is this section of the paper:

“Indeed, the Equihash parameters imply the total list length of 225 entries. The total number of hash calls per solution (without the difficulty filter) is 227:5, i.e. about 200 MHashes. Thus to match the hashing rate the ASIC must produce 100 solutions per second, and thus make 500 sortings of 225 entries per second. The hypothetical sorting rate is about 231 keys per second, or 10 times higher than GTX480 does for 32+128-bit keys. The necessary bandwidth 7 thus can reach 1 TB/sec, which is not reported yet for any memory chip, even for most advanced GPU.”

Keeping in mind the fact that this paper is from 2011 it still holds true that there are no GPU’s that have 1TB/s bandwidth, yet. Right now the Radeon Fury X has HBM and is capable of 512GB/s. And the HBM2 cards that are due out sometime late this year are finally supposed to approach the 1TB/s threshold.

AMD Radeon R9 Fury X Graphics Card Reviewed - The Tech Report

Theoretically it seems like when those cards do come out they would have an advantage, but that does not take into account that you still have to develop a miner that will run it efficiently enough not to fry it. Not to mention you will be hard pressed to find someone who is willing to open source the miner so everyone can use it, there are already guys on Slack talking about selling to the highest bidder. And we need to factor in how long will it take to recover the approx. $1000/card capital expenditure?

Furthermore, to somehow extrapolate that these GPU’s (that have not been relased yet) will magically have a 100x advantage in calculating Equihash is pure speculation and not rooted in fact.

Plus there is the elephant in the room that nobody is talking about: Plan how to change the proof-of-work · Issue #1211 · zcash/zcash · GitHub
What do you do when the developers see the network unbalanced by your shiny new HBM2 GPU farm and change the POW to make them less efficient?!

1 Like

just no mining equihash qwith gpu is more like 4x faster not more .

think I need to provide all the chips 1BTC, GPU mining software

weixin: mingfei858 请加微信吧

The Equihash GPU vs CPU was only a test of multiple cores sorting a single set of keys, which is not very applicable if you’re sorting 10 different sets of keys held in 8GB of on board GPU RAM at 25x faster bandwidth for only $400. It’s not 10/4 core x 25 = 62x faster as this implies because GPU cores are slow.

But the only way to block GPUs is to raise the RAM which will require you to raise the interval to 10 minutes or make the CPU solver faster (this is due to an attack issue), requiring 4.1 GB RAM per thread. This would give 16 GB desktops 3 threads to working, restricting 8 GB GPUs to 1 thread. You can get a 16 GB GPU, but they are expensive and the cores are slower.