Open robertfoss opened 7 years ago
You're absolutely right. And it was somewhat intentional. I'm quite sure that letting more threads to work on the same input is much less efficient then to run independent computations in different threads (due to obvious synchronization needs). I didn't implemented it so I cannot provide any numbers, but if I'm not mistaken there are other CPU miners trying to do this with the same conclusion - more independent computations are more efficient. At least for x86-64 CPUs. Then, running the solver in more threads is straightforward so I didn't understand it as a necessary part of the library.
Either you'll be doing inter process communication (or worst case repeatedly spawning miner processes) or you'll have to do inter thread communication.
I can't tell you which is the fastest, but from a user standpoint not having to maintain multiple processes is preferable.
I'm not sure if I understand you properly. You can use the library from one process from different threads without any limitation. Just use single instance of Solver class in each thread and you are fine. You can simply do it in C++ or we even did this from python (where multiple threads can be used because during the computation the threads needn't to have GIL locked).
Sure, you would need to create the threads yourself, but when I wrote the library, I didn't consider it as a problem. If the library supported threads It would have to provide more complex API because of e.g. nonce rolling, more complex solution reporting etc. I considered this as a responsibility of a zcash miner, not an equihash solver, so I didn't included threading support here.
It can be done for sure so I'll let this ticket open.
Thread support is currently lacking as far as I understand it.