About the genproclimit option. Is there any difference (memory-wise) on using one daemon spread over a many-core setup, or many dameon on many single-core setups?
I guess it’s the same? Or some of the memory can be shared on the many-cores setup?
The hashing bottleneck being the memory bandwidth, is it a problem to mine on many-core s - because the core would “fight” for the memory bus, or is it not a concern?
Zcash’s Equihash solver is not internally paralleized, so when you set genproclimit=(?) you are actually launching that many solvers to crunch Equihash. That’s why I don’t reccomend setting it more than the physical number of cores on your CPU.
If you have a 4core/8thread (ie: intel hyperthreading) CPU and set the number to 8 you can actually lose performance vs if you had set the number to 4.
I’ve seen the developers mention it before on Github, but it was ultimately decided not to do so because it would add unneeded complexity, plus the whole point of Equihash is to keep the playing field (somewhat) level between CPU and GPU.
I don’t know if you could/would be able to keep the desired 700MB per mining core requirement if it was internally paralleized.
When you use genproclimit=4 it seems to be about 4x more blocks gained than when using genproclimit=1, and I can’t tell a difference in machines that use DDR3 1333 and DDR3 1600, but the 1333 machines have a faster CPU. All the benchmarks I’ve seen have been indicating
solve speed = CPU speed x RAM bandwidth
And the consequences I see support it:
blocks gained = CPU speed x RAM bandwidth x cores
This assumes you run the solver with the miner off and on 1 thread.
I also have not been able to tell a difference in number of RAM cards. I can use an 8 GB in one slot, 8 GB in 2, or 4 GB in each of 4, and it’s all the same in terms of number of blocks gain on testnet.