Windows To Blame For Poor AMD ThreadRipper Performance

[Taf the Ghost]

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.

[Guest]

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

[Master Disaster]

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.

[RejZoR]

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).

[bitsandpieces]

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

[cj09beira]

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

[chazragg]

Just now, bitsandpieces said:

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

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

[bitsandpieces]

Just now, cj09beira said:

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

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

[Ashley MLP Fangirl]

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. 

[GoldenLag]

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

[bitsandpieces]

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?

[GoldenLag]

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

[GoldenLag]

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.

[bitsandpieces]

Just now, GoldenLag said:

also AMD64/x86-64 is a thing

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

[Ashley MLP Fangirl]

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. 

[bitsandpieces]

1 minute ago, GoldenLag said:

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

After they launched it?! HA!

[GoldenLag]

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. 

[GoldenLag]

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

[leadeater]

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. 

[bitsandpieces]

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?!

[bitsandpieces]

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?

[cj09beira]

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 

[GoldenLag]

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?

[GoldenLag]

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. 

[leadeater]

8 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?

To which the majority of applications performed as expected and the list that did not wasn't large and was already believed to be a Windows scheduler issue which Microsoft did release a patch for. For the applications that did not perform correctly it was thought to be those scheduler problems along with the remote memory to the 2 dies, good theory but not correct due to Linux not exhibiting the issue under the same conditions and software.

 

Complex problems are rarely found easily or fixed quickly, often go unnoticed until someone takes the time to investigate.

 

Failing to identify that there is an issue is not the same as there not being an issue, it's easy to cast judgment in hindsight but companies releasing new product don't have the luxury of operating in hindsight.