Home → Geekbench →

Linux vs. Windows results

• Edit

Artem S. Tashkinov

10 Jun, 2017 07:28 AM

Hi,

I'm curious why Linux and Windows results differ by quite a large margin: https://browser.geekbench.com/v4/cpu/compare/2979799?baseline=3067566

This is the same PC. Both tests have been run on a completely idle PC with next to zero background applications aside from system services. Windows performance profile was set to High Performance. I even changed Windows geekbench process priority to realtime - all to no avail.

Do you really use the same compiler for these two OS'es? If not, do you intend to? Otherwise your results between these two desktop OSes cannot be directly compared.

Regards,

1. 1 Posted by Anonymous on 23 Sep, 2017 12:49 AM

   

   I'm also interested.

   • Edit

2. Support Staff 2 Posted by Colin on 27 Sep, 2017 07:17 PM

   

   Hi,

   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.

   Best,
   Colin
   Primate Labs Inc.

   • Edit

3. 3 Posted by mleise on 09 Apr, 2018 04:14 PM

   

   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.

   • Edit

4. Support Staff 4 Posted by Colin on 10 Apr, 2018 02:48 PM

   

   Hi mleise,

   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.

   All the best,
   Colin
   Primate Labs Inc.

   • Edit

5. 5 Posted by b0b on 29 Apr, 2019 10:31 AM

   

   Look at this huge single-core difference for the Core i7-8850H between Linux (5817) and Windows (5233):

   https://browser.geekbench.com/v4/cpu/compare/12427650?baseline=12738264

   Confirmed by pages and pages of Linux score before the first Windows score for the top chart list for this CPU:

   https://browser.geekbench.com/v4/cpu/search?dir=desc&q=i7-8850H&sort=score

   Can we conclude Geekbench is not really suitable to compare scores for the same machine running different OSes ?

   • Edit

6. Support Staff 6 Posted by 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.

   • Edit

7. 7 Posted by b0b on 01 May, 2019 01:38 PM

   

   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 ?

   • Edit

8. 8 Posted by Artem S. Tashki... on 15 Jun, 2019 08:54 PM

   

   The discrepancy between Linux and Windows in the most recent GeekBench v4.3.4 has increased even further.

   It's high time you guys compiled it using the same compiler.

   • Edit

9. 9 Posted by Artem S. Tashki... on 24 Jun, 2019 08:53 PM

   

   13% difference between the OSes:

   https://browser.geekbench.com/v4/cpu/compare/13631495?baseline=13629401

   • Edit

10. 10 Posted by joe9000 on 02 Jul, 2019 07:34 AM

    

    John is likely correct. The dynamic power management throttling cores is a big unknown.

    Throttling is the default mode of operation these days. Particularly true for stock coolers and laptops.

    Without the clock rates of each core being recorded by each test as it runs, the amount of throttling can only be guessed at.

    • Edit

11. 11 Posted by joe9000 on 02 Jul, 2019 06:31 PM

    

    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.

    • Edit

12. 12 Posted by joe9000 on 02 Jul, 2019 06:46 PM

    

    Historically, the CPU clockrate was a known fixed value when running the benchmark. It has been a while since that was true, benchmarking tools just haven't kept up.

    Basically, benchmarking done without recording the associated clockrates lose much value.

    • Edit

13. Support Staff 13 Posted by 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.

    • Edit

14. 14 Posted by joe9000 on 03 Jul, 2019 09:01 PM

    

    John,
    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.

    • Edit

15. Support Staff 15 Posted by John on 04 Jul, 2019 04:48 AM

    

    Joe,

    Geekbench 4 records the maximum clockrate the system can achieve before running the workloads. You can see this data by appending .gb4 to the end of any Geekbench 4 result:

    https://browser.geekbench.com/v4/cpu/13631495.gb4

    The ~ was meant to indicate the approximate maximums -- it's much easier to understand ~4.2GHz than 4149MHz.

    • Edit

16. 16 Posted by joe9000 on 04 Jul, 2019 05:17 AM

    

    Cool! Didn't know about that. The Processor Frequency Mean could be what I'm looking for. Just need it added alongside each score.

    • Edit

17. 17 Posted by Marco.Leise on 04 Jul, 2019 05:18 AM

    

    #ignore

    • Edit

18. 18 Posted by joe9000 on 04 Jul, 2019 05:36 AM

    

    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.

    • Edit