Number of cores need to be specified at compile time?



The beta mining guide is awesome, thanks!

The compile command line however, is the following:

./zcutil/ -j$(nproc)

Does that mean the number of core used by the program need to be determined pre-compilation?

Or that can be changed in the conf file?

Does this concerns computation of transactions, or mining as well?



That line only applies to the the compilation step to help speed up the process. It's not used in mining or in the .conf file.

You can also use ./zcutil/ by itself without a processor argument it will just use one CPU to do the work.

If you want to use more cores for mining your can set genproclimit=4 in the .conf file. Change that number to however many cores you have.


Ok I see. Makes sense :slight_smile:

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.

Test it out for yourself, and feel free to post your results at


Do you think this is something in the future that will be improved upon?


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.


@zawy thanks for sharing your results, very interesting!