Thread replies: 24
Thread images: 5
Thread images: 5
File: better scheduling.png (105KB, 1002x714px) Image search:
[Google]
105KB, 1002x714px
>Scheduling in Windows is fine
Meanwhile:
>Games that do their own thread scheduling instead of relying on Windows to do it get a 35%+ performance increase
As a programmer, this shit pisses me off.
This expectation that hundreds of developers need to patch thousands of games instead of Windows patching once.
If Windows tried to keep all the threads of an application on one CCX, and only cross them over to another CCX.
Currently, Windows tries to balance the software threads each across the main hardware threads, and keeping the SMT ones lightly loaded, which means crossing CCX.
Nearly every game sees performance improvements by instead using the SMT threads of the same CCX instead of balancing load onto the second CCX.
There are games that can use all 8 cores and further increase performance by managing thread scheduling to tell the scheduler which threads ought to go on the other CCX, but the vast majority of games work fine when running on one CCX, thus that should clearly be the default things that work and management should only be needed for heavily intensive applications.
Most game developers are too incompetent to do their own thread scheduling like F1 2016 and Mafia III, and aren't going to patch this shit. And AMD takes the fall for Microsoft.
>>
>>59397701
Microsoft hires shitty devs
>>
>>59397701
yeah, anyone sane sees this, now why did AMD tried to mask this?
is it PR fuck up? it would've been better to keep silent about whole thing for now
>>
File: 1489488955111.png (37KB, 600x662px) Image search:
[Google]
37KB, 600x662px
>>59397701
>Windows scheduler is working fine
https://www.youtube.com/watch?v=DQilK2dOJTg
>>59397883
Huge PR blunder by AMD. The worst they should have said is "Windows is treating SMT fine, but we are investigating other issues". Instead they said there are NO problems with the Windows scheduler, which is 100% proven to be false.
>>
>>59397894
what the fuck, that video
difference was 70% in some places
>>
>>59397701
Are there any similar issues cropping up on Linux?
>>
>>59397925
it's mostly working as intended on linux
AMD themselves patched it in as far as I know
>>
Intel has spoken.
Too bad for them this won't help them at all in the datacenter.
>>
>>59397701
>Games that do their own thread scheduling instead of relying on Windows to do it get a 35%+ performance increase
Where the ungodly fuck are you getting that? If you're referencing your image, that's not what it says at all. It literally says that the 35% difference is gained from the software being configured wrong as a fault of the third party backup system. It has literally nothing to do with windows at all and everything to do with a weird, unforseen quirk of restoring a backup.
>>
>>59397894
MSFT is a big customer. AMD needs adoption from large companies more than consumers at this point.
>>
>>59397916
WINDOWS SCHEDULER IS WORKING FINE REEEEEE
>>59397925
Yes, the same issue exists on Linux where the scheduler doesn't seem to quite understand that it should try its best to keep all the threads of an application on one CCX. The schedulers don't seem to understand the latency moving some cross CCX, though they should.
Not that no applications should use both CCX, but when a game doesn't have much workload and it can all run in one CCX, trying to then split it across two CCX incurs a lot of latency trying to use each other's shared cache when the program isn't specifically written for 2 L3 caches.
>>59397948
No, what was fixed on Linux is just identifying which threads are SMT threads. The issue of being aware of its architecture and how there is an extra 100ns delay by crossing the CCX and being aware of most games relying on shared cache is not fixed.
>>59398042
So? They could have said "we're still investigating issues" to not throw MSFT under the bus but to acknowledge that something may not be working right somewhere.
>>59398034
Not getting that from the image. It's just a general statement.
See Mafia III. See the other videos that show it 35%+ better perf using with one CCX disabled.
>>
File: firefox_2017-03-14_09-45-22.png (16KB, 625x422px) Image search:
[Google]
16KB, 625x422px
>it's not the OS's fault (even though it clearly is) it's game developers
Fuck you, AMD.
>>
>>59398100
At least on linux someone can make the scheduler for you
>>
>>59398229
>down less than half a dollar
>despite still being higher than where it was when Bulldozer dropped
>>
>>59398932
Doesn't matter. Should be to the moon.
>>
File: Screenshot from 14-03-2017 16:12:00.png (20KB, 671x231px) Image search:
[Google]
20KB, 671x231px
>There's nothing wrong with Windows 1'
>>
>>59399253
Virtually the same with HPET off, peak power setting.
That is a core parking and not scheduling issue.
Windows 10 scheduler is virtually the same as Windows 7. It just core parks more aggressively.
>>
>>59399273
What does the high precision event timer even do?
>>
>>59397701
This is why I use Linux
>>
>>59400648
Linux does have the same issue of assigning threads across the CCX when it doesn't need to, though.
But I imagine it'll get fixed much faster on there.
>>
File: 1489507441726.png (96KB, 630x758px) Image search:
[Google]
96KB, 630x758px
Nothing bad is going on. Some games see gains and some games don't. It's a combination of issues including the way Win10 parks cores on balanced mode. Very few reviewers state if Win10 is set to performance mode or not.
>>
>>59402160
This is about the moving threads cross CCX, not SMT, you fucktard.
>>
>>59397701
Still don't understand why AMD isn't rightfully putting the blame on Microsoft.
Now the plebs will only see that AMD is shit on Windows.
Well, bravo, Bulldozer 2.0
>>
>>59403818
Because they don't want to upset MSFT :(
Thread posts: 24
Thread images: 5
Thread images: 5