Aber das hast du doch oben geschrieben, siehe Quote
PS: Du kannst doch sicher schneller nach deinen Beiträgen suchen, als ich, der erst mal dein Profil finden müsste...
War doch nur ein Beispiel... Wäre es eine Coreskalierung, müsste Ryzen überall gleich stark skalieren wie Broadwell-E. Ist aber eben nicht der Fall. Nicht mehr und nicht weniger steht dort. Allein die Tatsache, dass es offenbar unterschiedliche Skalierungsfaktoren gibt, belegen die Aussage. Egal ob das nun gut oder schlecht für Ryzen/Broadwell ausfällt.
Und nein, es geht dabei ausnahmsweise nicht darum zu bewerten, ob das nun gut oder schlecht ist, was Ryzen da abliefert (wieso habe ich das Gefühl, dass du die Aussage genau dahingehend drücken willst??), sondern ausschließlich darum, das ein Test, der derart viele unbekannte Baustellen durch einen Plattformchange über die Sockel hinweg, ohne fixe Taktraten, mit variablem Turbo, unterschiedlicher Bandbreite, verschiedensten CPUs, verschiedenen Cachegrößen/Geschwindigkeiten usw. usf. aufzeigt, einfach nicht taugt für eine Core-Skalierungsaussage. Nicht mehr und nicht weniger ist in die Aussage bitte auch reinzuinterpretieren!
Coreskalierung und ausschließlich Coreskalierung hätte bedeutet. Intel 8C/16T oder Intel 10C/20T Prozessor zu nehmen und pro Messreihe Cores zurück zu zu fahren. Taktraten dabei fix. Turbo deaktivert, Speicherbandbreite fix. Cachegröße fix, Cachespeed fix. Board identisch, GPU Identisch usw.
Das gleiche von mir aus im direkten Vergleich nochmal mit einem Ryzen Prozessor... Oder eben auch anderen Modellen in ähnlich "breit" -> Sandy-E bspw. oder nem alten Dual Core2Quad System, irgendwelchen Opterons oder was auch immer. DAS wäre ein Coreskalierungstest mit belastbaren Zahlen.
PS: #439 und #490 unter Anderen...
Simple Beispiele:
- Manche Spiele verteilen die Threads selbst auf die Kerne, gehen die uU. noch von einem Bulldozer Derivat aus, da AMD Family >=15h. Wenn man erst die Module voll macht ist das bei BD ok, bei Zen landet es auf den SMT Threads und blockiert.
- Man kann auch einfach mal auf Ryzen Debuggen und schauen, ob ggf. eine Funktion unerwartet lange dauert, weil der Compiler misst baut und hier ansetzten.
- Es gibt bei der Threadverteilung einen großen Unterschied was Win7 und 10 angeht.
Das der Komplette Code neu geschrieben wird erwartet glaub ich niemand...
Wie gesagt keine Frage, ich bin da voll und ganz bei dir, was den Grundtenor angeht... Nur wird man eben mit Optimierungen an der Stelle nur bedingt was drehen können. Software wird, vor allem bei Bezahlmich-Software irgendwann mal abgeschlossen. Da kann ich mir von solchen unschönen "Workarrounds" als Endkunde halt nix mehr von kaufen
PS: die zählweise der Cores/Threads bei Ryzen ist doch identisch zum i7... Das gleiche gilt auch für die Bulldozer Module.
Sprich jeweils die gerade oder die ungeraden Threads voll machen hat effektiv auch bei Ryzen den besten Effekt! Zumindest das, was ich bis dato über Ryzen und die Ermittlung der Latenzen beim Threadschubsen laß.
Was bei Ryzen "anders" ist, Thread 0-7 sind CCX0 und 8-15 sind CCX1. Jeweils gerade und ungerade, beginnend mit der kleinsten Nummer gehören zu einem physischen Core. Und genau in der Mitte wird zwischen den CCXen getrennt.
Der Intel mit SMT zählt dabei identisch nur ohne CCX Trennung -> logisch...
