Thanks for letting us know about this, and I apologize for the delayed response. The deviation in scores for those two configurations are slightly larger than normal, but not atypical for the difference between two runs on a given machine. Some specific workload scores, mainly the HTML5 DOM score, show an unexpected discrepancy which could be the result of a hardware issue or an intermittent background process, though with two results it is difficult to draw firm conclusions about its cause.
Linux and Windows do not use the same compiler. Some details on the compilers used for each platform are available via our page on the individual Geekbench 4 CPU workloads. Currently, there are no plans to change how Geekbench is compiled on a particular platform. Despite the different compilers, Geekbench should generate similar scores for the same hardware on average, though scores may fluctuate slightly.
I am seeing the same effect for a 2013 notebook. HTML5 DOM Multi-Core looks like it is running single-core on Linux. Also the AES, LZMA, raytracing and the memory bandwith test is usually "won" by Windows, while the others are "won" by Linux.
https://browser.geekbench.com/v4/cpu/compare/7080784?baseline=7873495 I believe most of it can be attributed to different compilers (at least in the single-core tests), while the HTML5 DOM discrepancy looks like a problem with threading support in the used library.
Thanks for letting us know about this. I'm not certain what would be causing your multi-core HTML5 DOM score on Linux to be similar to the single-core value. I've passed this information along to my team and will let you know as soon as I can if we can provide more information or an update to address this issue.
Similarly, regarding the differences between your Windows and Linux runs of Geekbench, we're continuously investigating any potential issues which could cause scores to differ between operating systems, and I'll take a closer look based on your information.
John on 30 Apr, 2019 03:50 AM
From the results you posted it looks like the CPU is able to hit higher frequencies under Linux than Windows (4.3GHz vs 4.2GHz). If one OS enables the processor to run at higher frequencies (and for potentially longer periods of time) I would expect that to be reflected in benchmark results.
Interesting. How do you know only 4.2 GHz was reached for the single core benchmark on Windows ? Have you looked to more detailed data of the benchmark report that is not displayed in the web UI ? Is there a way for users to check that in some way ?
I should have also have added that the 13% can be attributed to the higher percentages of desktops vs laptops that Linux installs will have. Desktops will have better cooling so won't throttle as strongly as the laptops do.
John on 03 Jul, 2019 07:23 PM
For the Ryzen 3600 results, this is another situation where the clock speed is higher under Linux than Windows. For the Linux result the system is running at ~4.4GHz, while for the Windows result the system is running at ~4.2GHz.
Switching to a different compiler won't solve this problem.
As you've indicated with the "~", those clock rates are your best guess at explaining the difference. If the actual dynamic clock rates had been recorded then that component of the score wouldn't be guesswork any longer.
There is something missing there though. I can't see a distinction between single-core workloads and multi-core workloads. Clearly, on some systems at least, the clock rate will come out quite different between the two.
This would need resolved to produce score-frequency pairs for both single-core and multi-core.
There is a very large difference between Windows and Linux multi-core scores on AMD 3990X CPU. In my case it's 26052 on Windows and 36217 on Linux. This is 28% difference. Is it due to the fact that Windows can't properly utilize more than 64 threads?
Windows 10 can use way more than 64 logical processors, but the application need to be compiled with that in mind, and it needs to understand processor group. If Geekbench doesn't do that, you won't get anywhere near a valid result.