Jump to content
To encourage social distancing, you must leave two blank lines at the start and end of every post, and before and after every quote. Failure to comply may result in non-essential parts of the forum closing. Click for more details. ×
Search In
  • More options...
Find results that contain...
Find results in...
BuckGup

Windows To Blame For Poor AMD ThreadRipper Performance

Recommended Posts

4 minutes ago, Taf the Ghost said:

Deep in the video, he runs a Windows in Linux setup and runs Indigo again. Numbers are roughly the same as a real Windows in control. (That's the "Indigo in WSL" & ~1.55 line in the graphics box in the thread start.) Wendel goes into the details, but it's not that the scheduler isn't aware of the NUMA nodes. When the threads are generated, the system spawns a suggested Thread list. It appears the first problem actually start after 16 threads, but the scheduler has a spillover effect and can handle another 16 threads. 

 

Actually, I think I just figured out much of what is going on. MS, to solve the Ryzen issues, just treats each CCX as a NUMA Node. With TR1, the scheduler patch just gave a near & far designation approach. TR2 -WX models end up being 16 NUMA Nodes and the Scheduler just can't handle going beyond 8 Nodes.

True though I'd still like to see a full VM and on ESXi as well because of the different scheduling methods in hypervisors and I'm not sure Windows in Linux is actually anything like Windows inside a VM detecting that it is in a VM.

 

I'm not actually expecting to see a difference but I think that kind of test is worth it.

Link to post
Share on other sites
3 minutes ago, leadeater said:

True though I'd still like to see a full VM and on ESXi as well because of the different scheduling methods in hypervisors and I'm not sure Windows in Linux is actually anything like Windows inside a VM detecting that it is in a VM.

 

I'm not actually expecting to see a difference but I think that kind of test is worth it.

Be interesting to see, I agree.

Link to post
Share on other sites

You should really start to worry when Linux is outperforming Windows lol 

Link to post
Share on other sites
8 hours ago, leadeater said:

Probably since it likely effects quad socket Intel systems too and if EPYC2 is as good as hoped there would be enough people demanding it be fixed, so long as they know about it needing to be fixed of course.

Knowing Microsoft they'll fix it, but only in Windows server.


Main Rig:-

Ryzen 7 3800X | Asus ROG Strix X570-F Gaming | 16GB Team Group Dark Pro 3600Mhz | Samsung 970 Evo 500GB NVMe | Sapphire 5700 XT Pulse | Corsair H115i Platinum | WD Black 1TB | WD Green 4TB | EVGA SuperNOVA G3 650W | Asus TUF GT501 | Samsung C27HG70 1440p 144hz HDR FreeSync 2 | Windows 10 Pro X64 |

 

Server:-

Raspberry Pi 4 Model B running OMV Arrakis and an 8TB Seagate USB 3.0 external HDD

Link to post
Share on other sites
1 hour ago, leadeater said:

True though I'd still like to see a full VM and on ESXi as well because of the different scheduling methods in hypervisors and I'm not sure Windows in Linux is actually anything like Windows inside a VM detecting that it is in a VM.

 

I'm not actually expecting to see a difference but I think that kind of test is worth it.

Usually there are means of detection. It was a common problem with malware where it was doing 2 different things depending on where it was being executed and how it detected that. If it ran native, it did its payload. If it detected VM, it just exited without a message or error or even did something harmless to give appearance that it's harmless.

It's possible regular apps also do some sort of detection and then function differently in either (sans malicious intents).

Link to post
Share on other sites
1 minute ago, bitsandpieces said:

Windows to blame??! MICROSOFT didn't develop THREADRIPPER, AMD did - was AMD not aware what they were doing?

amd made the cpu, its up to microsoft to make sure their software runs well on the hardware, not the other way around

Link to post
Share on other sites
2 minutes ago, bitsandpieces said:

Windows to blame??! MICROSOFT didn't develop THREADRIPPER, AMD did - was AMD not aware what they were doing?

AMD just made a very high thread count cpu. Windows was designed in a time where that wasn't possible yet, and to keep backwards compatibility they can't just change the entire kernel. 


They/Them 

Phone: Nokia 7.2 | 128GB | Android

Laptop: Apple MacBook Pro | Core i5 7360U | Iris 640 | 8GB RAM | 120GB SSD | macOS

Gaming PC: Asus Prime Z370-P | Core i3-8100 | R9 290X | 16GB RAM | 250GB SSD | Bitfenix Whisper | Windows 10

Link to post
Share on other sites
3 minutes ago, bitsandpieces said:

Windows to blame??! MICROSOFT didn't develop THREADRIPPER, AMD did - was AMD not aware what they were doing?

 

1 minute ago, chazragg said:

i get a vibe you didn't actually read anything past the title. 

i get the vibe he doesnt have too much overview over the subject. Software adapts to hardware, not hardware to software

Link to post
Share on other sites
Just now, firelighter487 said:

AMD just made a very high thread count cpu. Windows was designed in a time where that wasn't possible yet, and to keep backwards compatibility they can't just change the entire kernel. 

did they discussed it with MICROSOFT during their development? I'm fairly sure AMD had to test their architecture in a win environment - nowhere at any point in this did it ever come up?

Link to post
Share on other sites
1 minute ago, bitsandpieces said:

It's the other way around, AMD has to adhere to x86 specs and they went off rails

is this sarcasm?

 

this has pretty much nothing to do with unstruction sets. also x86 is instruction sets and not specs. also AMD64/x86-64 is a thing

Link to post
Share on other sites
Just now, bitsandpieces said:

did they discussed it with MICROSOFT during their development?

considering the time it took Windows to patch the Ryzen issue, yes. they did talk. 

Windows just couldnt scale to the amount of threads 2990wx offers. 

 

in other words. windows is at fault here.

Link to post
Share on other sites
2 minutes ago, bitsandpieces said:

did they discussed it with MICROSOFT during their development? I'm fairly sure AMD had to test their architecture in a win environment - nowhere at any point in this did it ever come up?

even if it did AMD doesn't have access to the Windows source code so can't fix the bug. the only thing they can do is report the bug to Microsoft. 


They/Them 

Phone: Nokia 7.2 | 128GB | Android

Laptop: Apple MacBook Pro | Core i5 7360U | Iris 640 | 8GB RAM | 120GB SSD | macOS

Gaming PC: Asus Prime Z370-P | Core i3-8100 | R9 290X | 16GB RAM | 250GB SSD | Bitfenix Whisper | Windows 10

Link to post
Share on other sites
1 minute ago, bitsandpieces said:

I applaud your knowledge, lack there of, AMD64 does not exist in a vacuum and it's not an architecture

It's purely an extension to the x86 architecture, nothing less .. nothing more

so its an extension of an instructionset that needs to be followed to run windows.

 

its a set of instructions, just like x86. 

Link to post
Share on other sites
1 minute ago, bitsandpieces said:

After they launched it?! HA!

you know how patching works yes?

how software and optimization development works

how things launch?

how to keep things secret up untill launch?

how it takes time to develop things?

 

windows sqedualler doesnt work with the 2990wx. its not the other way around. software is developed for hardware, not the other way around. it has allways been like this

Link to post
Share on other sites
5 minutes ago, bitsandpieces said:

I applaud your knowledge, lack there of, AMD64 does not exist in a vacuum and it's not an architecture

It's purely an extension to the x86 architecture, nothing less .. nothing more

This isn't a bug or issue with x86, it really has nothing to do with that at all. In fact AMD has zero control over this issue at all. All thread and cores are correctly exposed to the OS, the OS is the scheduler to which applications and services are allocated to those presented threads. AMD has nothing to do with that at all.

 

Linux has no problems at all, no magic or tricks it just reads the presented information from the CPU and allocates tasks to threads correctly.

 

If it were a design flaw with the CPU or something like going out of spec with x86 then it would be broken in Linux and that is not the case. 

Link to post
Share on other sites
Just now, GoldenLag said:

so its an extension of an instructionset that needs to be followed to run windows.

 

its a set of instructions, just like x86. 

It's a subset of, x86 can run very well without

What if MICROSOFT would've ignored AMD64 extension? AMD would've developed it for nothing; Thus AMD did collaborate on implemeting it into Windows x64, but they dropped the ball with TR and it's implementation in Windows

At this point, MS could give less of a flying fuck and ignore TR, at any point AMD thought it was necessary to have MICROSOFT involved?!

Link to post
Share on other sites
2 minutes ago, leadeater said:

This isn't a bug or issue with x86, it really has nothing to do with that at all. In fact AMD has zero control over this issue at all. All thread and cores are correctly exposed to the OS, the OS is the scheduler to which applications and services are allocated to those presented threads. AMD has nothing to do with that at all.

 

Linux has no problems at all, no magic or tricks it just reads the presented information from the CPU and allocates tasks to threads correctly.

 

If it were a design flaw with the CPU or something like going out of spec with x86 then it would be broken in Linux and that is not the case. 

So, you're telling me AMD tested TR on Windows (prior to launch) and found no issues, then what's the fuss all about?

Link to post
Share on other sites
2 minutes ago, bitsandpieces said:

It's a subset of, x86 can run very well without

What if MICROSOFT would've ignored AMD64 extension? AMD would've developed it for nothing; Thus AMD did collaborate on implemeting it into Windows x64, but they dropped the ball with TR and it's implementation in Windows

At this point, MS could give less of a flying fuck and ignore TR, at any point AMD thought it was necessary to have MICROSOFT involved?!

if they did that people would move over to another OS that would take the time to use the advantages of the new hardware.

btw thanks for the laughs 

Link to post
Share on other sites
Just now, bitsandpieces said:

What if MICROSOFT would've ignored AMD64 extension?

then we would all be using Linux or Mac. mostly because you want to be able to use more than 4GB of Ram. 

2 minutes ago, bitsandpieces said:

At this point, MS could give less of a flying fuck and ignore TR, at any point AMD thought it was necessary to have MICROSOFT involved?!

i mean shure, leave a broken system broken while the rest of the world watches their CPUs break as Windows cant handle the threads..........

AMD reports the bug to microsoft, it is then up to microsoft to do stuff about it. AMD contacts microsoft to add the CPU signatures if neccesary. where is AMD at fault for creating a very powerful and innovative product?

Link to post
Share on other sites
3 minutes ago, bitsandpieces said:

So, you're telling me AMD tested TR on Windows (prior to launch) and found no issues, then what's the fuss all about?

AMD probably found issues and reported them to microsoft. and as of today nothing has happened. we have known this being an issue as of launch. and Microsoft probably known earlier than us. 

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Announcements

  • April fools topics should be posted in Off Topic

×