you can already tell by disabling the smt that some games don't seem to care about it, so with it enabled there will hardly be a difference.

Yeah, but it's not those cases we care about. We already know many games are not properly multi threaded and only use anywhere from 1-4 threads effectively. What we care about is how performance will be on something that can properly use 8 threads + 8 SMT threads. No one's expecting AMD to beat out an i7-7700K in current gen games, but with the right software support the Ryzen chips should definitely beat out the 7700K in anything. DX 12 brings better performance for multi threaded CPUs. So expect better game performance when developers actually code their games to properly make use of 8 + 8 SMT threads, then a little more when DX 12 is properly used.

when Microsoft was build their scheduler last years they didn't take in account other procesors than intel

Did anyone made game benchmarking in windows 7 with dx11 games and compare them with windows 10 to see difference in max fps in 1080p or maybe even windows 7 scheduler doesn't work properly with ryzen?

This^! I really want to know if Ryzens works properly with W7 or if W10 is "mandatory" for Ryzen to work at 100%. I want to build a new rig and continue to use W7 so it would be great to know if Ryzen works as it should under it. Otherwise my only option is to stick with Intel...

SMT performance may not improve much due to Ryzen's cores (physical/logical) being statically partitioned in some areas, and resource competitive in others. So, when using a logical SMT core, it effectively halves many pieces of the physical core structures. Micro-op queue, for example, is statically partitioned between physical/logical. ALU/AGUs are competitively tasked between physical/logical using algorithms (one thread pushing more instructions will cause it to jump ahead in resources versus other thread). Microcode updates can improve that a little if the algorithms aren't efficient. I'm not sure if the static partitions can be made dynamically resource sensitive, so if you're only using 1 physical thread, it gives that thread the entire micro-op queue, instead of remaining halved even though a logical thread isn't active. The CCX structures are definitely throwing Win10's scheduler for a loop. Time sensitive threads or operations should definitely NOT be crossing between CCX0 and CCX1, as that introduces added latency (less maximum FPS, and random drops if dependent threads cross CCXs). Inter-CCX communication is limited by memory bandwidth, so running faster memory helps, but compared to L1-L3 cache bandwidths, it's not an efficient route. So, Win10 should treat the CCXs as NUMA nodes, as they have their own caches, like 2 complete CPUs joined by an interconnect. On PS4 and Xbox, there is a massive penalty for each 4-core group of Jaguar cores to communicate with each other. So, they've tasked them as NUMA nodes to prevent that. Ryzen will likely be similar in that regard. Do I expect massive gains? No. Measurable and noticeable, very likely, if used effectively.

https://www.youtube.com/watch?v=40h4skxDkh4

Let me explain it from what I understand, someone correct me if I'm wrong. The SMT thread uses leftover or unused resources of a core to get maximum use out of the core. A core is made of many components, and even if it's used to "100%" as Windows's task manager (but not others) may show, it's not common for all the parts of the core to actually be in use at the same time. A program is pretty much never (aside from stress tests) going to use exactly all the resources a core has, it needs certain amounts of certain things in a certain ratio, that means there will be something left unused generally and can't make use of that remainder because there isn't enough of other resources (the ratio I talked about). SMT is a clever way of scheduling to make use of those available resources which adds up to quite a bit when you have multiple cores. So this means the SMT thread is nowhere near as powerful as the main thread of the core, it's not simply 2 threads attached to one core. One is a standard thread, the other is cleverly using leftover resources. Both threads have to be in use at the same time to saturate a core. Though I thought I read in the past that Intel (at the time, this was a long time ago) did include a minor amount of extra physical components in their SMT CPUs. This was so long ago it may have been with a Netburst chip or derivative with their first implementation of Hyper Threading. I have no idea if that still holds true today, but I doubt it. I've asked about this at least once before but no one had an answer.

As far as I read a while back the threads are implemented hardware-wise as well, yes. Which is why some i5 processors clock higher than their i7 counterparts (logic would dictate that i7s would be better binned otherwise). However what you said kinda makes sense too I guess, I'll have to dig into this. Maybe I'll perform some single-threaded benchmarks on each thread at a time to see if there are significant differences. I just imagined there are 2 identical hardware threads attached and the scheduler gives them appropriate access to the core. On the software side, Windows knows which is a hyperthread and doesn't oversaturate it. The reason why I'm slightly questioning what you said is because during a core stall (say, a cache miss) the second thread should be able to access all of the core's resources until the CPU hears back from the main memory. In this case, having the second thread only access part of the core would be a severe handicap.

Technically I don't think it's a "bug". Current Windows are simply not Ryzen-ready. MS just needs to add support for the new HW and hence modify some things in the kernel. Notice also Linux requires new kernel: https://www.phoronix.com/scan.php?page=news_item&px=AMD-Ryzen-Newer-Kernel It's not a "bug".

when Microsoft was build their scheduler last years they didn't take in account other procesors than intel

Especially processors which are not released yet. Gurus don`t mix up "thread" and "core". Thread is entity of executed code and core is facility (either logical or physical) to execute the code. SMT is about several logical cores per physical one. Threads are all the same from scheduler point of view - i.e. they all can be dispatched to any core in system (unless thread is pinned to certain core). Threads only differs in properties like priority and state. Scheduler may take into account the nature of core (SMT or not) - considering that when thread is executed on any logical core belonging to same physical core the cache of that physical core still contains previously cached data.

As far as I read a while back the threads are implemented hardware-wise as well, yes. Which is why some i5 processors clock higher than their i7 counterparts (logic would dictate that i7s would be better binned otherwise).

Whether or not Intel add extra hardware for their SMT CPUs, the CPUs not using SMT are going to clock higher because they'll simply heat up less. It makes a pretty big difference in temperature, or at least did with Haswell. The last time I tested mine at high clocks and voltage I was getting over 20C lower temps with Hyper Threading off. I had the same results with older generations like Nehalem.

The reason why I'm slightly questioning what you said is because during a core stall (say, a cache miss) the second thread should be able to access all of the core's resources until the CPU hears back from the main memory. In this case, having the second thread only access part of the core would be a severe handicap.

I'm not entirely sure what you mean by that. Seems backwards to me. Then again I should have been asleep like 6 hours ago, at least, so my brain is not here right now. :wanker: I don't know enough about how the process works to give you a proper explanation. That's something you'll have to look up or maybe someone else here can answer.

They said the same thing about Bulldozer and the patches did nothing.

They said the same thing about Bulldozer and the patches did nothing.

Yeah, it was something like 1% or less from what I saw. But this is entirely different. Bulldozer was a steaming pile of crap sharing components between its fake cores making optimized scheduling a hassle... but it turned out to suck so much that even when optimized there wasn't much of a gain. This is real cores with the SMT threads being treated like real cores. This sounds like it really would have a notable negative impact on performance. Don't expect performance increases in old games or other stuff that use few threads. But I do expect real improvement in properly multi threaded applications. Let's hope for the best. Please don't be 1% or less. :wanker: Edit: Aaaand I just realized it doesn't matter how many threads a program uses, if it incorrectly has it's load dumped on an SMT thread thinking it's a real core that's going to cripple performance. Yep, time to take a nap.

They said the same thing about Bulldozer and the patches did nothing.

Yeah. Honestly, don't just believe everything AMD say guys. I'm not going to say they're lying or misleading, it seems, from everything they've said, that the issues are everyone else's fault and not theirs. There might end up being good improvements but just wait out and don't blindly spend money on something that they claim needs quite a bit of fixing.

Yeah. Honestly, don't just believe everything AMD say guys. I'm not going to say they're lying or misleading, it seems, from everything they've said, that the issues are everyone else's fault and not theirs. There might end up being good improvements but just wait out and don't blindly spend money on something that they claim needs quite a bit of fixing.

The report about the "bug" is coming from Microsoft....not AMD.

I don't have my 1060 yet, but I noticed just playing some games with an old 750ti I had none of the cores hit 100% constantly. One or two threads show near 100%, but average is about 40%.

The report about the "bug" is coming from Microsoft....not AMD.

Yeah, but it's coming from Microsoft's customer support twitter. I doubt they know much about kernel engineering teams and what they are working on. The part I find weird is that AMD just won't come out and acknowledge that it's an issue with Windows. When PC Perspective asked AMD why it was happening, if it was fundamental to the pipeline, an issue with SMT, or what.. AMD just repeated that they needed to work with game developers. All they'd have to say is "Hey, we found issue(s) with the way Windows handles threads/cache/smt/ccxs/parking etc, we are working with Microsoft to resolve these problems" I feel like tons of people would be more relieved and it would end all the guessing over whether it's going to be fixed or not. Since they aren't doing that and still keep repeating the game dev line, maybe the issue isn't with Windows/chip at all and it's like they are saying.. some games just aren't suited to run well on the platform and need updates or we just need to wait for games that are more optimized before getting a better picture.

AMD has its own dirty past and this makes me a bit skeptical about Ryzen's performance being low because of bugs and patches. There are some things that need optimization sure but I can hardly believe we will see any significant performance gains in games. I just don't believe you can patch hardware with software and expect magical performance gains. I think many people will be disappointed when they found out that even after the patches and bios gaming performance will remain the same. I say about gaming performance because Ryzen rocks in everything else except gaming.

So they claim it's a windows issue. But AMD surely test the finished product on all versions of windows before releasing? Therefore what does that say about their testing procedure? Sounds like baloney to me.

Not sure I would ever go back to using an AMD CPU now. I've used Intel CPUs since I upgrade from an AMD Athlon X2 many years ago to an Intel Core i7-920 in 2008. To be honest, they simply haven't produced anything to rival Intel until now and while they might be cheaper than Intel I'm someone who only buys a new CPU every 3-5 years anyway so I'm happy to pay a bit more to have something that not only lasts but also works properly with Windows and games. You get what you pay for at the end of the day IMO.

So they claim it's a windows issue. But AMD surely test the finished product on all versions of windows before releasing? Therefore what does that say about their testing procedure? Sounds like baloney to me.

It's possible their testing found the issue, but depending on the problem it could take several months to fix. Under most workloads the processor is exceptional for the price it's at. It wouldn't make much sense for AMD to delay the entire launch several months because it's a few % behind in some games at one resolution. Smarter decision would be to release it and just let people know they are aware of the issue and are working with Microsoft on a fix. Which they didn't do either.. but yeah.

Not sure I would ever go back to using an AMD CPU now. I've used Intel CPUs since I upgrade from an AMD Athlon X2 many years ago to an Intel Core i7-920 in 2008. To be honest, they simply haven't produced anything to rival Intel until now and while they might be cheaper than Intel I'm someone who only buys a new CPU every 3-5 years anyway so I'm happy to pay a bit more to have something that not only lasts but also works properly with Windows and games. You get what you pay for at the end of the day IMO.

But that's the thing re cost they arent cheaper from what I can see...if you are say comparing against something like a 7700k or a 7600k. (which can do around 5ghz). @Denial sorry to say any company that tests products and finds issues and still releases a product needs a good slap in my opinion. Period.