Question Intel 14900 is significantly faster under Linux compared to Windows 11 ?

[BBL_414]

I recently ran a simple benchmark on my Intel 14900-based system, comparing Linux (debian) versus Windows 11.
The benchmark launches a number of threads which just do md5 hash calculation from memory - so completely cpu bound.
The results showed that the archieved thruput was significantly less on Windows 11 compared to Linux, around 30%, or around 620 MB/s versus 850 MB/s average rate per thread. The CPU is at 100% in both cases.

Does someone have an idea where the performance difference comes from?

I can provide the benchmark tool if someone wishes to run it on their system.

 

[Dragos Manea]

Windows 11 "great" optimization, it is well known that ubuntu is much better optmized and has more performance ( and it is much lighter on resources) compared to windows.

 

[BBL_414]

Both Linux and Windows 11 idle at 0.0 to 0.3% cpu load, so background processes should be no problem.

I cant see a reason why lack of optimization could reduce the performance of a rather high-end cpu by that much, that would require more explanation.

 

[Moonstick2]

Think about it logically: the processor isn't going to perform MOV/ADD/AND/XOR/etc instructions at different speeds according to which OS sends them, is it? So it's going to be entirely down to the assembly code itself.

Even though they probably use the same md5 algorithm, the software's also doing things like requesting memory and threads. Those things require OS calls, so you're at the mercy of how well the OS does those kinds of things. Multiple threads means the OS thread scheduler also comes into play.

The processor hasn't somehow got faster; Linux is just making better use of it.

 

[BBL_414]

Said benchmark launches a constant number of threads, each thread allocates a fixed memory buffer - after that its cpu only. The md5 hash implementation comes from the dotnet core framework, same on all platforms.

I can publish the source code here, if someon wants to see how their system performs.

I wouldnt be surprised if linux is more efficient than windows, but if windows is 30% slower i would call it a piece of s...

 

[TerryLaze]

Those things require OS calls, so you're at the mercy of how well the OS does those kinds of things.

But also it could be that windows monitors every OS call looking at what's going on making sure it's safe, while linux just lets software do whatever it wants...
Just an assumption, I have no idea if it's so or not.

 

[Moonstick2]

I can publish the source code here, if someone wants to see how their system performs.

The source code doesn't matter, because it's the compiled assembly that counts. One source code file can produce two very different assembly programs according to what compiler, what library and what level of optimisation was used.

Said benchmark launches a constant number of threads, each thread allocates a fixed memory buffer - after that its cpu only. The md5 hash implementation comes from the dotnet core framework, same on all platforms.

There are two possibilities:

1) The 14900 performs instructions like MOV and XOR at different speeds according to the OS origin of identical software issuing identical instructions through the CPU somehow knowing which OS is relaying those instructions to it, or

2) One OS performs differently to the other because of its syscall code and/or the way the program was compiled.

Feel free to pick one, but I'd say the second is obviously the right answer.

 

[BBL_414]

The benchmark is written in c#, so the compiler is the same for all platforms. Framework binaries are the same as well.
And i doubt a microsoft compiler would produce severly less optimized binaries for a windows/x86 target

 

[kerberos_20]

The benchmark is written in c#, so the compiler is the same for all platforms. Framework binaries are the same as well.
And i doubt a microsoft compiler would produce severly less optimized binaries for a windows/x86 target

try to disable memory integrity in windows, see if that helps

 

[gamerk316]

Assuming the code compiles roughly the same between Linux/Windows, the most likely explanations are the threading models (Windows is much more likely to move threads around and result in a cache miss) or just the sheer number of background threads Windows has in the background relative to Linux. Remember, even if a thread does almost no work, it's still stopping an MD5 worker thread for a period of time.