BeezleBug schrieb:
sehr gutes Video zu wieso, weshalb, warum
[...]
https://www.youtube.com/watch?v=6laL-_hiAK0
ich hab mit dem video so meine probleme, ich sag nicht, dass das nicht stimmt, was sie sagen, aber das fazit ist irgendwie fragwürdig.
und zwar genau deshalb:
https://www.youtube.com/watch?v=U9DE83lMVio
achtet mal auf die auslastung von core1 (bzw eigentlich "core 0") das ist der erste physikalische kern. im smt teil von dem bench ist die aufteilung so:
core1: phys. core 1
core2: smt core 1
core3 phys. core 2
core4 smt core 2
usw usf.
bei win7 ist die auslastung auf core 1 immer im hohen 90er bereich (soll auch so sein, ist ja cpu limit). bei win10 schwankt die auslastung auf core1 aber ständig und teilweise extrem, weil win10 die last von core 1 auf die anderen verteilt, denn die last von spielen ist extrem asynchron, bei gleichmäßiger last (multithreaded) ist die auslastung auf allen kernen gleich, und win10 balanced nichts. wenn man den "haupt"thread von einem spiel ständig zerrupft und auf andere kerne aufteilt, kann das ja schonmal nicht so gesund sein.
es geht noch weiter:
ryzen ist ja in CCX (verbund von 4 kernen, jeder kern hat einen L2 chache) aufgebaut. ein CCX hat einem gemeinsamen (victim) L3 cache. die verbindung zwischen den CCX ist der infinity fabric, der läuft momentan mit 1/2 ram takt (was mit ddr4 2600 = 1300mhz extrem niedrig ist). der delay von ccx1 zu ccx2 (mit langsamem ram) ist ca drei mal so hoch wie die kommunikation bei intel, dafür ist die interne kommunikation der ccx doppelt so schnell wie bei intel.
threads die ccx-intern stark miteinander kommunizieren profitieren extrem von der geschwindigkeit im ccx - threads die außerhalb des ccx kommunizieren werden entsprechend ausgebremst. das ist kein "fehler", ist halt ne eigenart von dem design.
nun schiebt aber win10 die auslastung munter zwischen ALLEN threads hin und her, und das scheinbar zufällig, AUCH in die andere CCX, und hier wirds dann richtig hässlich, weils hier "datenstau" gibt wie hölle.
das problem mit dem load balancing ist definitiv vorhanden, und die schlechtere performance bei der kommunikation zwischen den CCX ist fakt. zu sagen, windows 10 macht hier nix falsch und der scheduler ist unschuldig, obwohl threads zwischen ccx1 und ccx2 balanced werden, ist definitiv falsch.
umso erstaunlicher ist es, dass bei CB für win7 kein performanceplus rauskommt?!?!? weil win7 nämlich in der regel zuerst die phys. kerne füllt und die last nicht vom ersten kern weg"balanced".