CPU Mining: Optimal Number of Threads

Question

(I guess this question in principle applies likewise to Bitcoin, but given how un-profitable CPU mining of Bitcoin seems to be, this question actually arose with regards to Yacoin mining).

I am currently using the AVX version of the 64-bit Windows miner whose link can be found on Yacoin's homepage. As with all forks of minerd, you can specify how many threats minerd should use for mining. It seems as if the default number it uses is the number of logical processors, which in my case happens to be 8. I've tried playing around with this value, however, and it seems that playing around with the number of threads can significantly increase my hash-rate (of course it can also decrease it). I guess this came as a bit of a surprise as I just assumed that the default thread count would have been the most efficient.

There is also the variable of how many workers I have running on the pool (in my case, yac.coinmine.pl) and how many processes of minerd I am running.

This means that there are various combinations of process count / thread count I could play around with to try to find the most efficient combination, but before I figured I'd spend the time playing with these various possibilities, it would be easier to just ask someone who has a better idea of how this actually works: Is there any reason it would be beneficial to run 8 instances of minerd with 1 thread each vs 1 instance of minerd with 8 threads each? Perhaps in principle there shouldn't be, but because I'm mining in a pool the fact that separate instances require separate workers makes a difference? What should be an ideal thread count and why should this actually be an efficient thread count to use? For example, using 16 threads seems to improve my hash-rate over that of just using 8, but doubling again to 32 threads seems to lower the hash-rate again. Why would this be the case?

As a separate but related question, why does my hash-rate seem to slow the longer the miner runs?

Answer 1

One instance of minerd is all you're going to need. The application also synchronizes with the pool. So opening more than 1 instance of minerd is just going to cause your network to be used twice for the same information. Also, the operating system has some overhead for running the application. Opening another instance will mean more overhead and thus less hashes!

You have a CPU with hyper-threading, so you have 8 logical cores, this is not the same as having 8 physical cores. Have you tried running it with 4 threads (just for fun)?

---

Also, imagine having a racetrack with 4 lanes. You can drive 8 or 16 cars on it. But you'll still have to let 4 cars drive side-by-side at a time. You can throw any amount of cars at it as you want, but someone is going to have to synchronise those cars, so that'll just mean the racetrack is used less.

Ideally you should have 8 cars on a 4 lane racetrack. This way the cars that have exited the racetrack have some time to exchange their lap times while the other 4 cars use the racetrack. They can then almost perfectly relieve each other, like a relay race.

Having less than 4 cars on this racetrack means the racetrack will not be used all the time, since the racers in the cars want to exchange their lap times with each other after exiting the racetrack (the processes want to give back a result to the minerd thread).

Having more than 8 cars means there will always be cars waiting to enter the racetrack, so you'll just have cars waiting a lot of time before they can race on the racetrack.

Answer 2

When I used Slackware and compiled my kernels, there was a recommendation to set threads 2xN - N=number of cores. But here http://www.databook.bz/?page_id=2319 I found a guy, not sharing this opinion. Obviously it varies on the different platforms. So, if yours observations show that 2xN works better on your machine, this sounds reasonably.

Answer 3

I have an I3 330M laptop with 2 cores and 2 threads per core. Setting the thread value of m-minerd to 2 threads instead of the default of 4 threads did not in any way impede performance, while going with 4 threads seemed to be ever so slightly less efficient. Sounds like Jonathan Gleason has had a similar experience. My speculation, then, is that m-minerd or the mining process itself is not conducive to hyper-threading (or, using more than one thread per core). Anyway, that's been my experience. Yeah, it's an old post but I thought I'd give a mention.