Core locked threads + fibers are pretty good for cache locality (both L1 & L2). You have core locked 7 worker threads (1 core reserved for OS). 4 on the first cluster, 3 on the other. Data migration between two 4 core clusters really hurts on Jaguar. There are several ways to solve this.
Easy improvements include:
- Schedule top level task to selected cluster (for example rendering & physics to cluster 0). IIRC a commercial physics lib is configured by default to use only cluster 0.
- Restrain sub-tasks to same cluster (including wide parallel for loops).
- Work stealer prefers stealing from the same cluster. Only steal from threads of other cluster if work can't be found otherwise.
In case of SMT you'd want to steal work first from the neighbor SMT thread, because it shares L1 and L2 cache (on Intel and Ryzen). Then steal from other threads in the cluster cluster (8 threads out of 16 on Ryzen). Last steal from everybody (otherwise you would just stall). Prefer stealing top level tasks from other cluster instead of pieces of parallel for loops. Each task should have data dependency info (low, medium, high) that describes how much it is dependent on parent task's data. This is just a rough estimate that programmers can tune if they notice bad cache behavior. Scheduling and stealing would use the data dependency info to optimize the cache usage. This is pretty simple way to solve most of the problems. On PC you of course need to trust Windows API that tells you the core and cache configuration. Unfortunately this API gives wrong info currently for Ryzen. Hopefully fix is coming soon.
Some task graph systems track read/write resources (like the new DICE GDC presentation). This allows you to schedule tasks to SMT cores and clusters in more efficient way. Resource = chunk of memory. Scheduler could simply try to keep accesses to each resource in the same cluster. Not a problem if you build the task graph at the beginning of each frame. This is simply a graph sorting/binning problem.
https://community.amd.com/community...4/tips-for-building-a-better-amd-ryzen-system
There are differences between W7's and W10's power plans, so "balanced" on W10 can hurt the performance.
There are differences between W7's and W10's power plans, so "balanced" on W10 can hurt the performance.
Ike Turner
Veteran
Wut!
would be interesting to see if this applies to other games (even if this is probably just minor as I hope/think that most benches were done on a clean install)Ike Turner
Veteran
The game has to be un-installed and re-installed which is most often not the case for most players who keep their steam games library on a different HD than the one the OS is installed so they don't have to re-download them every time to recover/format/whatever there Windows install.Would be easy for that game to be patched to trigger generation of maps on startup.
Next ppl would come to complain that switching cpus while playing is not suported
Last edited:
Just look around and you will find test with difference around 10%. And I'm not talking about random youtubers. I think even stilt make some tests.
Enviado desde mi HTC One mediante Tapatalk
The two operating systems are complex systems, so there is going to be a difference. Whether AMD considers that an issue is not the same thing. There are trade-offs that might hurt performance in other non-game scenarios, or platform power efficiency (going for no core parking for example) that could be an issue for someone else. Given the rawness of the platform, AMD may simply assume that it's going to be rough in some place regardless. AMD's general statements are that there are various secondary issues, and in a few cases individual fixes, but not a singular cause.
Currently, it is not. Multiple reviews have it capping out at sub-DDR3200, and one constraint for compatibility being cited is the fixed 1T command latency.
This appears to be an area where the immaturity of the architecture is evident, and memory controllers and interconnect are an area where a lot of tweaking happens under the hood late in development.
Rizen's dependence on this may indicate that AMD was hoping that the chip could reliably get to the next speed grades, but that so far this is the best they could do stably.
The Anandtech thread has discussion of internal debug modes for 1:1 clocking of the fabric with the headline DRAM speed, although that might be more of a room to grow testing option for some future instance--or for some chip with way lower clocks. Getting clocks closer to the core speeds does lower latency somewhat, and perhaps some future review can monitor of there are certain sweet spots where the fabric, MC, and core clocks are at convenient multiples that minimize synchronization cycles.
Yes right now is hard to find kit for 3200 that work on ryzen but in the future users will have a real reason to buy (super expensive) fast ram kits in the oposite of Intel where the diference is very low.
Also more than 32% in F1 from worse case scenario to best case scenario is huges, thats like 2 generations jump in performance(5 with Intel strategy) .
I think I will wait until R2 to buy a system or maybe getting a chip 4/8 for 150~ when they came out and update from then.
Also more than 32% in F1 from worse case scenario to best case scenario is huges, thats like 2 generations jump in performance(5 with Intel strategy
) .I think I will wait until R2 to buy a system or maybe getting a chip 4/8 for 150~ when they came out and update from then.
How likely do you think it is that we'll see a new stepping with improved memory/interconnect performance before Ryzen 2 is out?
Hopefully AMD's tweaks allow for stable operation at higher speed grades and more DIMMs. The official support at even the sub-3200 speeds for a single-rank DIMM per channel would leave customers buying fewer of these high-speed modules, which might not make a kit maker happy.
I'm not sure how important continuity of DIMM support within speed grades counts, although presumably AMD would want healthier DRAM speed and capacity support per channel for Naples, if they have similar controllers and fabric.
There's also Raven Ridge as a product that would have a stronger case for robust memory support.
I keep wondering when a 16-core quad channel product is supposed to show up. The gap between Rizen and the announced Naples is vast in core and channel count, and the intermediate core and channel count is what AMD's design philosophy leaves as a way to match Intel's quad-channel sockets.
Validation of server parts are very complex and difficult, AMD needs to do it right at the first try so they have to take the time needed to do it right. Also you need a ecosystem and right now partners are busy fixing the few models they launched and are not very happy with the way amd threat them in this launch.
So Naples is still away and there is no date so I would expect end of the year maybe?
Enviado desde mi HTC One mediante Tapatalk
So Naples is still away and there is no date so I would expect end of the year maybe?
Enviado desde mi HTC One mediante Tapatalk
Per AMD, Naples is to be available in Q2 2017.
http://www.anandtech.com/show/11183...aples-cpus-for-1p-and-2p-servers-coming-in-q2
I think I've read somewhere that there will be 16-core (and 24-core?) versions of Naples available as well. That's what you'd expect, anyway.
On further reflection, the Naples system used by AMD had DRAM density and speed matching the DIMM count for Ryzen at 2400. The chip Naples faced off with isn't any faster, so Ryzen's relatively pedestrian speeds for enthusiasts could be related to the datacenter market being more important than high-speed gamer kits.
Similar threads
