Linked by Thom Holwerda on Mon 10th Jul 2017 18:27 UTC
Windows

This story begins, as they so often do, when I noticed that my machine was behaving poorly. My Windows 10 work machine has 24 cores (48 hyper-threads) and they were 50% idle. It has 64 GB of RAM and that was less than half used. It has a fast SSD that was mostly idle. And yet, as I moved the mouse around it kept hitching - sometimes locking up for seconds at a time.

So I did what I always do - I grabbed an ETW trace and analyzed it. The result was the discovery of a serious process-destruction performance bug in Windows 10.

Great story.

Thread beginning with comment 646603
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Apples and oranges
by karunko on Tue 11th Jul 2017 18:58 UTC in reply to "RE: Apples and oranges"
karunko
Member since:
2008-10-28

On old hardware, with less CPU power running an old version of Windows, you would expect the problem to be much worse.
But it was not!
This shows, that it is mainly a problem/bug of newer versions of Windows (after Win7).

No it doesn't. He didn't try Windows 10 on the older hardware so we just don't know what would happen with that particular workload. In other words, both of you are making assumptions and my questions still stand. ;-)


RT.

Reply Parent Score: 2

RE[3]: Apples and oranges
by krebizfan on Tue 11th Jul 2017 19:46 in reply to "RE[2]: Apples and oranges"
krebizfan Member since:
2017-07-11

He probably should have tried Windows 10 and Windows 7 on the same hardware to get an accurate measurement of how the two differ. Especially since the problem correlates to the number of threads which is related to the number of cores. However, it is very likely that it would still show Windows 7 to be better in that specific use case. Windows 10 redesigned the end of process to be faster by in part not giving as much time to the rest of the system. This saves battery life.

With a system such as described, where many threads are created and instead of being closed as they finish are all closed at once in the end, the cumulative effect of all the thread closures being bunched together is an unresponsive systems for a duration. Every code design decision carries with it the risk of unusual code performing worse.

Reply Parent Score: 1

RE[3]: Apples and oranges
by cybergorf on Tue 11th Jul 2017 21:58 in reply to "RE[2]: Apples and oranges"
cybergorf Member since:
2008-06-30

"On old hardware, with less CPU power running an old version of Windows, you would expect the problem to be much worse.
But it was not!
This shows, that it is mainly a problem/bug of newer versions of Windows (after Win7).

No it doesn't.
"

Sure, it does.


He didn't try Windows 10 on the older hardware so we just don't know what would happen with that particular workload. In other words, both of you are making assumptions and my questions still stand. ;-)


irrelevant.
Or you are the one making the illogical assumption, Win10 works miraculously faster on much older and less powerful hardware.

Reply Parent Score: 0

RE[4]: Apples and oranges
by CATs on Wed 12th Jul 2017 06:52 in reply to "RE[3]: Apples and oranges"
CATs Member since:
2017-06-09

Sure, it does.

No, it really, really does not.

irrelevant.
Or you are the one making the illogical assumption, Win10 works miraculously faster on much older and less powerful hardware.

Relevant. You are also just making and assumption. No matter how logical or "obvious", it's still an assumption that has NOT been tested in real life.

Reply Parent Score: 1

RE[4]: Apples and oranges
by Soulbender on Thu 13th Jul 2017 11:14 in reply to "RE[3]: Apples and oranges"
Soulbender Member since:
2005-08-18

Sure, it does.

Not at all, actually.


Win10 works miraculously faster on much older and less powerful hardware.


If Windows 10 is slower (likely) or faster on the much older hardware is not relevant. What is relevant is if the same underlying issue is present.

Reply Parent Score: 2