DragonX/hush3
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Do not lock cs_main in mining code

Browse Source 
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:
Duke
2024-09-20 13:35:38 -04:00
parent f3995fa1b7
commit 792fec7689
1 changed files with 4 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
src/miner.cpp
View File

@@ -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);