WyvernTKC / cpuminer-gr-avx2

Optimised Version of GR miner for RTM
GNU General Public License v2.0
371 stars 193 forks source link

Add some core leveling logic when running with less threads #141

Open HLalumiere opened 2 years ago

HLalumiere commented 2 years ago

It would be useful to add some core leveling logic to the miner, so that if you are running for example on 14 threads on a 16 threads CPU, it's not just the one core that remains completely unused all the time. After ending one thread's work, spawn another thread on a different core. Randomize affinity regularly in other words. That would allow hot cores to cool down, and cool cores to boost higher initially, as well as spread the wear and the heat around more. I think it should allow higher performance and cooler temps, especially on Ryzen or Threadripper... Thanks!

PS, XMRig got nothing on you, still the best cpu miner for gr!

TheFou commented 1 year ago

+1

WyvernTKC commented 1 year ago

Hey!

Thanks for the idea. We will look into it!


From: HLalumiere @.***> Sent: Sunday, November 28, 2021 1:18:19 PM To: WyvernTKC/cpuminer-gr-avx2 Cc: Subscribed Subject: [WyvernTKC/cpuminer-gr-avx2] Add some core leveling logic when running with less threads (Issue #141)

It would be useful to add some core leveling logic to the miner, so that if you are running for example on 14 threads on a 16 threads CPU, it's not just the one core that remains completely unused all the time. After ending one thread's work, spawn another thread on a different core. Randomize affinity regularly in other words. That would allow hot cores to cool down, and cool cores to boost higher initially, as well as spread the wear and the heat around more. I think it should allow higher performance and cooler temps, especially on Ryzen or Threadripper... Thanks!

PS, XMRig got nothing on you, still the best cpu miner for gr!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/WyvernTKC/cpuminer-gr-avx2/issues/141, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ASXNF3ZBN4Y4LZ7Z3YEP643UOGNPXANCNFSM5I4ZSYKA. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

michal-zurkowski commented 1 year ago

GR is very cache context dependent and it might lead degraded performance. The no contex swich where 1 core is mining should be quite long (in CPU time scale ofc) that it would heat it up to almost max anyway. And switching from core to core with every hash is not optimal due to lost cache context. Miner still selects single threads from cores first, so to see any "real' benefit like you mention, you would have to use like less than half the available threads in the first place.