Windows 11 vs. Linux Performance For Intel Core i9 12900K In Mid-2022

[coder]

Citations needed. You could be thinking about 7200 RPM 2.5" SCSI enterprise drives, well, boohoo, laptop drives are nowhere near close in terms of seek times.

It was so good, it won Storage Review's Editors Choice award.

https://www.storagereview.com/review/western-digital-velociraptor-1tb-review

[birdie]

It was so good, it won Storage Review's Editors Choice award.

https://www.storagereview.com/review...tor-1tb-review

Thanks for proving my words. Enterprise 2.5" drives that is.

[coder]

Thanks for proving my words. Enterprise 2.5" drives that is.

I didn't say it wasn't. I mean, that's basically what the Raptor series was, after all. My point was just that some high-end drives actually went to 2.5", whereas you stated that 2.5" was a liability for performance.

I've heard of other drives juicing their seek times by short-stroking (i.e. only using the outer portion of the platter). At some point, someone probably realized that instead of shipping a big platter and using only part of it, they could just move to lower-diameter drives which I guess you could probably also run at higher RPM.

[birdie]

I didn't say it wasn't. I mean, that's basically what the Raptor series was, after all. My point was just that some high-end drives actually went to 2.5", whereas you stated that 2.5" was a liability for performance.

I've heard of other drives juicing their seek times by short-stroking (i.e. only using the outer portion of the platter). At some point, someone probably realized that instead of shipping a big platter and using only part of it, they could just move to lower-diameter drives which I guess you could probably also run at higher RPM.

I was talking about laptop 2.5" drives which had always been terribly slow. I've no idea why you decided to intervene and refute me without actually refuting me. "Oy, mate, well, there are these 2.5 super fast enterprise drives, they are not so slow!" While I was replying to a person who had complained specifically about his laptop 2.5" drive. Oh, God.

Some people on Phoronix love to disagree with me in principle. OK, mate, you have defeated me in your argument. Great. Take a cookie! Only I had a different one.

[arQon]

Both of us can post anecdotal evidence that "it just works" and then what?

What's not anecdotal and easily proven is that Windows has reliably had accelerated fullscreen video in the browser for more than 10 years, whereas Linux basically got it this month. (Sort-of, maybe, but not really until another couple of months from now). While birdie didn't specifically call out the "browser" part, given that that's where the vast majority of video is watched on desktops these days I don't think it's unreasonable to give him the benefit of the doubt on that part - but it remains true whether you do or not.

supported_features.png

[andyprough]

What's not anecdotal and easily proven is that Windows has reliably had accelerated fullscreen video in the browser for more than 10 years, whereas Linux basically got it this month. (Sort-of, maybe, but not really until another couple of months from now). While birdie didn't specifically call out the "browser" part, given that that's where the vast majority of video is watched on desktops these days I don't think it's unreasonable to give him the benefit of the doubt on that part - but it remains true whether you do or not.

supported_features.png

It's an amusing xkcd cartoon, but honestly, if the reason you are installing a GNU/Linux distro is "so I can watch Netflix in full screen", you really have some messed up concepts of how you prioritize your time and energy.

[coder]

I was talking about laptop 2.5" drives which had always been terribly slow. I've no idea why you decided to intervene and refute me without actually refuting me.

What you said was:

"... thus slow and doubly so since they feature 2.5" platters."

So, I was merely pointing out that 2.5" doesn't necessarily make it slower. The only thing it impacts is the peak media transfer rate, if you hold the RPM constant relative to a 3.5" drive. However, media transfer rates aren't the primary bottleneck for running an OS off a HDD -- the issue is really seek times. Since a 2.5" drive has a shorter stroke than 3.5", the seek time should tend to be better, not worse.

"Oy, mate, well, there are these 2.5 super fast enterprise drives, they are not so slow!" While I was replying to a person who had complained specifically about his laptop 2.5" drive. Oh, God.

In point of fact, it was neither specified this was a 2.5" nor a laptop drive. Just that it was portable. I didn't take issue with your assumption, because it's quite plausible that it was both. It's important to be mindful of the knowns and unknowns.

Some people on Phoronix love to disagree with me in principle.

I'd have written the same reply no matter who posted what you said, but you seem to take everything so personally. Maybe if you don't see this as some kind of contest, but just somewhere that we can trade stories and information, it would help you see there really aren't any stakes in it. Not everyone is going to agree with you, but if you aren't seeking validation, then that shouldn't really matter. And if you try not to be too defensive, you might learn more from these discussions.

OK, mate, you have defeated me in your argument. Great. Take a cookie! Only I had a different one.

This does nothing for me. I'm not here to beat you or anyone else. I'm here to learn and share information, so the main thing I want is sharing of good quality information.

[coder]

It's an amusing xkcd cartoon, but honestly, if the reason you are installing a GNU/Linux distro is "so I can watch Netflix in full screen", you really have some messed up concepts of how you prioritize your time and energy.

I disagree. Lots of us use small x86 & other machines connected to our TVs, for streaming video. Since the mid-2000's, people have been using Linux for HTPCs (ever hear of Myth TV?).

For me, it really didn't involve any more time & energy to use Linux than Windows for this. Possibly even less, since I know Linux so much better. And if your machine isn't x86, but maybe something like a Pi, then Windows often isn't even an option.

[NobodyXu]

If it's block-based, then it wouldn't. You'd just read the block twice, but those are small enough they could be buffered internally by the library.

Either way, I'm not really sure how relevant this is to the performance discrepancy. Sure, if the test reads the entire file twice, and the file is too big to stay in the page cache, then any problems Linux has with sub-optimal read-ahead could be exacerbated. I guess that's your point?

I did not do much research about the readahead in windows vs linux, but I think they should perform similarly when the entire file is read twice.

Imho there isn't anyway for them to reliably predict whether the whole file is going to be read again, and I don't have any knowledge on windows' readahead being more advanced.

Thus I think the performance difference is mostly because the scheduler in Linux isn't as optimized for ADL as Windows.

[coder]

I did not do much research about the readahead in windows vs linux, but I think they should perform similarly when the entire file is read twice.

If the entire file is read twice, then one of two things will happen:

1. If there's enough free RAM, the file will be sitting in the page cache and read-ahead will be eliminated from the picture on the second pass.
2. If there's not enough free RAM to cache the entire file, then you'll take 2x the hit of reading it once. This would amplify any effect of insufficient read-ahead.

Imho there isn't anyway for them to reliably predict whether the whole file is going to be read again,

Right, at least if you don't take the trouble to use fadvise. So, Linux will generally cache as much of the file as it can, using a page-based LRU (Least-Recently Used) eviction policy.

and I don't have any knowledge on windows' readahead being more advanced.

I wasn't talking about sophistication, though that's another possibility. I was merely talking about the fixed amount of read-ahead, on Linux.

Thus I think the performance difference is mostly because the scheduler in Linux isn't as optimized for ADL as Windows.

Could be, but it's a big leap to take on the basis of not much data.