Do not lock cs_main in mining code
Technically we should take this lock but it has never been there before and it leads to potentially large slow downs when mining with multiple cores. We see basically the same hashrate for a single core if we have the lock or not and that makes sense, since there is only one core, there are no other mining threads that have to wait. But on one particular CPU I saw a 6% slower hashing when mining with 2 threads and 35% slower with 3 threads. This change also means debug builds will coredump if mining is enabled.
This commit is contained in:
@@ -1320,8 +1320,7 @@ void static RandomXMiner()
|
||||
}
|
||||
|
||||
CValidationState state;
|
||||
{ LOCK(cs_main);
|
||||
|
||||
//{ LOCK(cs_main);
|
||||
if ( !TestBlockValidity(state,B, chainActive.LastTip(), true, false))
|
||||
{
|
||||
h = UintToArith256(B.GetHash());
|
||||
@@ -1332,8 +1331,7 @@ void static RandomXMiner()
|
||||
fprintf(stderr,"\n");
|
||||
return(false);
|
||||
}
|
||||
|
||||
}
|
||||
//}
|
||||
SetThreadPriority(THREAD_PRIORITY_NORMAL);
|
||||
LogPrintf("HushRandomXMiner:\n");
|
||||
LogPrintf("proof-of-work found \n hash: %s \ntarget: %s\n", B.GetHash().GetHex(), HASHTarget.GetHex());
|
||||
@@ -1692,8 +1690,8 @@ void static BitcoinMiner()
|
||||
fprintf(stderr," mined %s block %d!\n",SMART_CHAIN_SYMBOL,Mining_height);
|
||||
}
|
||||
CValidationState state;
|
||||
{ LOCK(cs_main);
|
||||
|
||||
//{ LOCK(cs_main);
|
||||
if ( !TestBlockValidity(state,B, chainActive.LastTip(), true, false))
|
||||
{
|
||||
h = UintToArith256(B.GetHash());
|
||||
@@ -1704,7 +1702,7 @@ void static BitcoinMiner()
|
||||
return(false);
|
||||
}
|
||||
|
||||
}
|
||||
//}
|
||||
HUSH_CHOSEN_ONE = 1;
|
||||
// Found a solution
|
||||
SetThreadPriority(THREAD_PRIORITY_NORMAL);
|
||||
|
||||
Reference in New Issue
Block a user