mine: hash on every core instead of one (#52)

Satoshi left a note above ThreadBitcoinMiner in 2009:

    //// todo: start one thread per processor,
    ////       use getenv("NUMBER_OF_PROCESSORS")

Nobody did, and it stopped being a nicety when the proof of work
became RandomX. SHA-256d on a 2009 desktop lost little to a
single thread. RandomX is built to be fed by every core at once,
so one thread on a 32-core machine mines at a thirty-second of
what the box can do -- and the only outward sign is a CPU that
looks suspiciously idle. A user reported exactly that: 30 minutes
of "Mining", no blocks, Bitflash sitting at 3.3% CPU while the
2 GB dataset was allocated and fast mode was active. Nothing was
broken. It was hashing on one core.

  bitflash -gen                     # every core but one
  bitflash -gen -genproclimit=8     # exactly eight

Automatic leaves one core to the rest of the node -- accepting
blocks, talking to peers, drawing the window -- because a node
that mines beautifully while falling behind the chain has won
nothing. /genproclimit overrides it, and a count several times
the core count is refused rather than quietly thrashing.

The wrapper was already built for this: RandomXCreateMinerVM says
"own VM, not shared", and the ~2 GB dataset is one allocation
every thread reads. Only the 2 MB scratchpad multiplies, so
sixteen threads cost about 32 MB more than one. The startup line
says so, because "why is it using 2 GB" is the first question
anyone asks.

Two things had to be right for this to be safe:

  - Shutdown. Miners share slot 3 of vfThreadRunning and StopNode
    waits for every slot before DBFlush tears the database down.
    With several, the first one out announced that everyone had
    finished while the rest were still calling ProcessBlock, so
    they are counted now and only the last one clears the flag.
    The three CheckForShutdown(3) calls inside the miner became
    plain returns: _endthread() does not unwind on Windows, so
    the bookkeeping would have been skipped there.

  - Duplicated work. Each thread makes its own key, and the
    coinbase pays it, so every thread has a different merkle root
    and searches a different space. Block assembly was already
    under cs_main and cs_mapTransactions; AddKey and ProcessBlock
    take their own locks.

Verified on both platforms: four distinct thread ids reach the
hashing loop and all report back on shutdown, which exits 0 with
DBFlush running. Auto picks cores-1 (1 on a 2-core box, correctly
reported). Speedup itself needs a many-core machine to show and
has not been measured here -- the claim in this message is about
threads doing work, not a benchmark.

Not touched: RandomX's memory. RANDOMX_DATASET_BASE_SIZE and
SCRATCHPAD_L3 are part of the hash function, so a knob for "use
more RAM" would either do nothing or fork the chain. Threads are
the only real dial.

1 files changed, 52 insertions, 6 deletions

diff --git a/src/net.cpp b/src/net.cpp
index 2581578..9ee056f 100644
--- a/src/net.cpp
+++ b/src/net.cpp
@@ -10,6 +10,7 @@
 #undef snprintf
 #endif
 #include "headers.h"
+#include <thread>          // hardware_concurrency, for the miner thread count
 #ifdef _WIN32
 #include <winsock2.h>
 #endif
@@ -1224,18 +1225,63 @@ void ThreadMessageHandler2(void* parg)
 
 
 
-//// todo: start one thread per processor, use getenv("NUMBER_OF_PROCESSORS")
+// Satoshi's "todo: start one thread per processor" stood here since 2009 and is
+// what MinerThreadCount() and StartMinerThreads() below finally do -- by way of
+// std::thread::hardware_concurrency rather than NUMBER_OF_PROCESSORS, which only
+// ever existed on Windows.
+//
+// Miners share slot 3 of vfThreadRunning, and StopNode waits for every slot to
+// go false before the node tears the database down. With one miner that was the
+// same thing as "the miner finished"; with several, the first one out would
+// announce that everybody had finished while the rest were still hashing and
+// still calling ProcessBlock. So count them, and let only the last one leaving
+// clear the flag.
+static CCriticalSection cs_nMinersRunning;
+static int nMinersRunning = 0;
+
 void ThreadBitcoinMiner(void* parg)
 {
-    vfThreadRunning[3] = true;
-    CheckForShutdown(3);
+    int nThreadId = (int)(intptr_t)parg;
+    CRITICAL_BLOCK(cs_nMinersRunning)
+    {
+        nMinersRunning++;
+        vfThreadRunning[3] = true;
+    }
     try
     {
-        bool fRet = BitcoinMiner();
-        printf("BitcoinMiner returned %s\n\n\n", fRet ? "true" : "false");
+        bool fRet = BitcoinMiner(nThreadId);
+        printf("BitcoinMiner thread %d returned %s\n", nThreadId, fRet ? "true" : "false");
     }
     CATCH_PRINT_EXCEPTION("BitcoinMiner()")
-    vfThreadRunning[3] = false;
+    CRITICAL_BLOCK(cs_nMinersRunning)
+    {
+        if (--nMinersRunning <= 0)
+        {
+            nMinersRunning = 0;
+            vfThreadRunning[3] = false;
+        }
+    }
+}
+
+// Start the miners. Returns how many actually got off the ground.
+int StartMinerThreads()
+{
+    int nThreads = MinerThreadCount();
+    int nStarted = 0;
+    for (int i = 0; i < nThreads; i++)
+    {
+        if (_beginthread(ThreadBitcoinMiner, 0, (void*)(intptr_t)(i + 1)) == (uintptr_t)-1)
+            printf("Error: _beginthread(ThreadBitcoinMiner) failed on thread %d\n", i + 1);
+        else
+            nStarted++;
+    }
+    // The dataset is one allocation shared by all of them; only the 2 MB
+    // scratchpads multiply. Printed because "why is it using 2 GB" is the first
+    // question anyone asks.
+    printf("Mining with %d thread(s) of %u core(s) -- about %d MB "
+           "(~2080 MB shared RandomX dataset + ~2 MB per thread)\n",
+           nStarted, std::thread::hardware_concurrency(), 2080 + 2 * nStarted);
+    return nStarted;
 }