They only said it in the context of how much more was possible with parallelism, given a base solve rate that was not fully utilizing the BW. That was my first question after reading it: how is anyone to know what the minimum base solve rate will be? People have frequently said it is B.W. limited, but that is not what the paper says.
Why would anyone choose to use Zcash instead of Monero again ?
Because ZCash is about zkSNARKs and cryptography, and mining is just a way of turning electricity into tokens. ZCash is more private to use. Mining is not using.
The truth is, industrial mining improves the security of blockchains. If a cryptocurrency can be CPU mined, it can be attacked by botnets. Botnet controllers have no stake in the survival of the currency, so they can make the most money by shorting the currency then attacking it. Industrial miners, on the other hand, have physical assets that lose their value if the currency loses value.
ZCash’s innovations are the use of zero-knowledge proofs to provide true privacy. Monero and Dash rely on obfuscation to achieve partial privacy for users, but they don’t come close to what ZCash provides. How ZCash gets mined is mostly irrelevant.
Anyway, Monero also has a 3x advantage for GPUs over CPUs, so it’s not much different from my results so far.
6 Likes
Calling ring signatures obfuscation is just retarded. GPU advantage in cryptonight is less than 50%.
1 Like
I wasn’t referring to the ring signatures. Monero obfuscates the amounts. ZCash makes the amounts completely secret.
An R9 290 costs less than $200 and gets >700 H/s on cryptonight. An i7 4790k costs 330 and gets around 350 H/s. That's around 3.5 H/(s*) for GPU, or 1 H/(s*$) for the CPU.
https://docs.google.com/spreadsheets/d/1E0GqJdLhMmeO5BW3RBcIpftMR_BJhnyUS464ZO_EYGQ/edit#gid=0
1 Like
Tell us more about the trusted seed ZCash needs to kick-start its genesis block… If someone was to hack/crack this seed he would be able to create zcash out of thin air without anyone noticing… Thanks but no thanks, I’ll stick with Monero.
Let’s try to keep this thread about this GPU and CPU miner, not about Monero.
3 Likes
A Tesla K40c GPU costs $3k and gets less than 500H/s, while an Intel Xeon E5-2680 v3 costs 1.5k and gets 1.2KH/s.
Spreadsheet you attached is ancient and no longer valid.
Let’s try to keep this thread about this GPU and CPU miner, not a rehashed debate about Monero.
1 Like
Last night ZCoin launched.
People were mining with i7 CPUs hashing at like 1Khash/s while my old 7850 was hashing away at 80Khash/s. The i7 CPUs are like $300 and the 7850 is like $30 these days.
Every algorithm is different. But GPUs will always be a better mining device compared to CPUs.
Do you imply you posted the “simple math” further in that comment? And that it shows the claim to be wrong through the Sol/s speeds calculated from available bandwidth to be much higher than what you’re seeing? If so, this doesn’t convincingly disprove the claim to me, because you have no proof that higher speeds (not necessarily those you calculated) are not possible and that your “1 GiB” and “10 times in a run” figures would be optimal for the highest-performing algorithm. Maybe, just maybe, the highest performing algorithm (achieving whatever performance higher than yours) would in fact bump into the memory bandwidth. Do you agree with what I am saying here, or am I missing something? I do not mean to sound negative - on the contrary, I’d like to learn from you, as I haven’t gone as far as you have in experimenting with Equihash. I also like to question claims, just like you do - and am questioning your claim this time. 
Thanks.
@solardiz The argument I’m making is that higher speeds are possible, at least as far as bandwidth is concerned. The argument that performance is limited by bandwidth makes sense conceptually, since sorting takes a lot of memory accesses and not much computation, but if you do the math, the math doesn’t even come close to agreeing. Even if you’re pessimistic with your assumptions, as I was, the calculated possible solution rates according to bandwidth do not match with actual solution rates. Something else is limiting performance.
It is difficult to improve sorting performance substantially. This has nothing to do with bandwidth, and more to do with latency, synchronization, and parallelization. We’ve done better at some stuff, but we’re going to face diminishing marginal returns eventually as we get close to the optimal algorithm.
Eventually, yes, we might hit the bandwidth limit. We’re far from that still.
We did not break Equihash. We just got less bad at it. Still keeping the details to myself, sorry.
This matches the argument made by the Equihash authors, who pointed out that (older) published sorting speeds showed a 4x advantage where the bandwidth advantage was 17x. So yes, Equihash is not practically bandwidth-limited because there are other limits that kick in first, but it’s still the case that the bandwidth limit is a limit, should it ever be reached.
2 Likes
We had a performance regression today. The R7 370 went down in performance from ~260 ms per run to ~310 ms per run. We think we know why, so we’ll revert those changes once we finish testing.
We also started testing an R9 290 4GB. It’s getting 185 ms instead of 310 ms, or 67% faster.
I might be abandoning the CPU miner for a while to focus on the GPU miner. I’m going to put in a few more hours and see if I can fix a nasty bug that’s been plaguing me, and if I can’t figure it out, I’ll move on.
Uhm, 34 minutes later, and we’re down to 110 ms on the R9 290. I guess [redacted] works.
Is there much interest in the CPU miner? I could abandon my work on it entirely and just focus our efforts on the GPU miner, or I could spend a bit of extra time and try to maintain progress on both. I think I could probably get the CPU miner to around 2 sec per core, or maybe 4 Sol/s on a 4.4 GHz quad-core CPU. There’s no way it will be competitive with GPU miners, but maybe there’s a niche application it could be useful for? Other than botnet mining?
3 Likes
do you plan to release this gpu miner before zcash launch? your answer will determine if i want to invest further in rigs or not.
@fomosapiens: I believe this has been answered. Basically it’s unclear at this point, but you’ll understand the full reasoning and options if you read all @jtoomim messages in this thread, or you could just read the first one.
10x. It was a 172 GB/s GPU RAM verses 17 GB/s DDR3. But jtoomim’s point is very different from that. The Equihash paper does not say B.W. is a limitation, but that it is an opportunity under given constraints. jtoomim is not exploiting the opportunity. He’s saying (and the paper does not disagree) that for a given system, B.W. is not relevant if you manage to need each byte an average of only 10x. His 4.7 S/s for a CPU is biased high by 2x or 3x because he used ideal read speed and no latency (or maybe he does not need to write??), but if 2 S/s is the actual limit, what makes zcashd only 0.05 S/s, and limited to 2.74x for 4 cores? The 2.74x implies it’s accessing memory 1/3 of the time when there is only 1 core. That implies it is accessing memory 2 / 0.05 x 1/3 x 10 = 133 times per solve where he only needs to do it 10x.
That implies it is accessing memory 2 / 0.05 x 1/3 x 10 = 133 times per solve where he only needs to do it 10x.
L2 cache hits don’t count. That’s usually 90% for a CPU. You’re also not touching every byte on every round.
Latency is also usually a bigger factor in CPU memory performance than bandwidth.
Thanks, I was recalling from memory and must have mixed the 10 and 17.
The 4 cores are not multithreading within a single solver run, but for independent solver runs. Not only does that mean an individual solver is non-optimal, but there is nothing implemented to negotiate or optimise memory allocation between the independent threads, meaning that memory contention is probably occurring more often than for an implementation that is written with multithreading inside a single solver run.