News Intel Core 300: 6 Modelle von Wildcat Lake bringen 18A in den Massenmarkt

[latiose88]

Dann dürfte diese CPU wohl meinen Intel Core i7 4700hq wohl um den Faktor 2 oder 3 übertreffen oder nicht ? Und das obwohl dieser HT hat und so also 8 Threads.

 

[Tigerfox]

Mir wird zwar gerade erst bewusst, dass schon seit längerem bei Intels 15W-CPUs die 7er die gleiche Core-Config haben wie die 5er, aber bis Meteor Lake unterschieden die sich wenigstens noch in der IGP und dem Cache.
Bei Meteor Lake-U und Arrow Lake-U war es tatsächlich auch schon so, dass alle U5 und U7 die gleiche Config hatten und sich nur durch Takt und Pro-Features unterschieden.

Ebenso ist es bei Intel normal, dass selbst der beste 7er der 15W-Klasse eine viel schlechtere Konfiguration hat als die lahmste CPU der H- und zuletzt auch P-Klasse (also 28W). Nur bis Alder Lake-P gab es noch einen i3, der schlechter als ein i5 Alder Lake-U war (mehr E-Cores als i3 ADL-U, genauso viele wie i5, aber IGP wie i3).

Trotzdem kommt es mir idiotisch vor, dass einen Core 5 315 und Core 7 360 nur wenige hundert MHz trennen, die im Einsatz bei 15W TDP wahrscheinlich ohnehin selten zum Einsatz kommen, und dass selbst ein Core Ultra 5 325, bei zwar nominell 25W TDP, aber auf 12W absenkbar.

Der idiotische Core Ultra 5 322 ist dagegen schlechter als der der Core 5 320 und nahezu identisch mit dem Core 5 315 - abgesehen von den PCIe-Lanes, nehme ich an.

Intel ist wirklich ein Meister darin, viel zu viele sinnlose SKUs auf den Markt zu werfen. Absolute Verschwendung von Silizium.

 

[latiose88]

Diese vielen Bezeichnung und so ,das verwirrt ja einen als es was gutes zu tuen.

 

[Piktogramm]

Das SMT auf einen Kern macht den Kohl nicht fett, zumal es Intels nicht so geile HT-Umsetzung ist.
Dazu sind die LPE-Cores x mal schneller als der Gracemont-Krams aus dem Jahr 2020, und natürlich auch der P-Core, der 2 Architekturen weiter ist. Also gerade für Low Power Mobile ist das ne ganz andere Liga.

Wie kommst du darauf, dass Intels Umsetzung von SMT "nicht so geil" sei? Intels Zuwachs an Durchsatz mit aktivem SMT ist nicht so groß wie bei AMD. Was aber daran liegt, dass AMD mit nur einem Softwarethread auf der CPU wesentlich mehr Ressourcen der CPU brach liegen hat (50% vom Frontend liegen brach). Entsprechend sind die Gewinne von SMT bei AMD auch deutlich höher, was aber kein Zeichen dafür ist, dass SMT bei Intel schlecht ist.
Was SMT bei Beiden gut kann ist eine bessere Ressourcennutzung zu etablieren, wenn es mehr aktive Softwarethreads als physische CPU-Kerne gibt. Bei der 1+4 Config würde SMT auf dem P-Kern da eine 20% Steigerung bedeuten und bei den größeren Modellen um 33%. Das wäre durchaus was, gerade beim Windowsprozessspam zu dem Microsoft/Windows neigt.

Und deine Ausage zu den LPE-Cores. Die LPE-Cores haben normalerweise das Problem keinen L3-Cache nutzen zu können. Geringer Takt, mangelnde Lokalität der Daten wiegen weit schwerer als die architektonischen Fortschritte der Architektur. Da würde mich interessieren, ob da die Aussage. dass da ein Faktor "x" an Geschwindigkeit besteht (Vergleich Gracemont mit L3 zu Darkomont LPE).

Ergänzung (1. April 2026)

Für Schreibmaschine + Medienkonsum reicht das immer noch. Für mehr aber wirklich eher nicht.

Ich kenne Unternehmen, wo 3D CAD produktiv auf langsameren CPUs läuft und die professionellen GPUs in den Kisten sind vom Durchsatz her auch langsamer als zwei 2x Xe3 liefern können sollte.
Zugegeben hatten wir auch schon Fälle wo "Texteditoren" allein beim Anzeigen eines blinkenden Cursors einen ganzen CPU-Kern auslasteten -.-

 

[Tigerfox]

Hat Wildcat Lake nun eigentlich ein Single- oder Dualchannel Speicherinterface? Core 7 mit Singlechannel käme mir arg beschnitten vor.

 

[Deinorius]

Ich bin auf den Vergleich sowohl mit günstigen Arrow Lake, aber insbesondere mit Lunar Lake Laptops gespannt! Gerade letztere fangen bei €700-800 an gerade die GPU-Leistung wird besser sein. Mal sehen, wie sich Wildcat Lake bei der CPU und Akkulaufzeit meistern wird.
Wenn diese Modelle nicht auch für teilweise €600 zu haben sein werden, sieht es nicht gut aus. Aber warten wir mal ab. Ich finde allein ein ThinkPad E14 mit Lunar Lake für unter €900 durchaus ansprechend.

@Batigol040 Für Schreibmaschine + Medienkonsum reicht das immer noch. Für mehr aber wirklich eher nicht.

Ich würde das etwas differenzierter betrachten. Spiele werden ja auch gehen, man muss sich halt etwas stärker einschränken als z.B. mit Lunar Lake. Und Videoencoding über die iGPU sollte auch gehen. Selbst mittels CPU sehe ich Möglichkeiten, sofern man einen Encode nicht innerhalb von wenigen Stunden und 4K haben muss.

 

[Piktogramm]

Hat Wildcat Lake nun eigentlich ein Single- oder Dualchannel Speicherinterface

Single Channel laut folgender Folie von Intel

Grob 51..55GB/s Speicherdurchsatz.

Imho, WildCat ist der Nachfolger von Core-N, da kann Intel erzählen was sie wollen.

 

[uberLemu]

WildCat ist der Nachfolger von Core-N

Da sie aber mehr Geld für Wildcat wollen, macht das nach unten eine Lücke im Portfolio auf. Dort würde Core-N dann weiterlaufen. Könnte auch eine kurzfristige Entscheidung gewesen sein, aufgrund des aktuell kaputten Hardware-Markts.

Wo steht eigentlich die Konkurrenz in dem Bereich? Mendocino macht noch ein fünftes Jahr?

 

[mae]

Wie kommst du darauf, dass Intels Umsetzung von SMT "nicht so geil" sei? Intels Zuwachs an Durchsatz mit aktivem SMT ist nicht so groß wie bei AMD.

Vor kurzem habe ich gemessen, dass ein Kern eine Ryzen 8700G (Zen 4) mit SMT zweimal dieselbe Aufgabe 1.35 mal schneller ausfuehren kann als wenn man sie hintereinander laufen laesst (der Zuwachs an Durchsatz also). Beim Core i5-1135G7 (Tiger Lake/Willow Cove) ergab der selbe Test mit aehnlichen Aufgaben einen Durchsatzzuwachs von 1.14. Das ist schon deutlich schlechter.

Was aber daran liegt, dass AMD mit nur einem Softwarethread auf der CPU wesentlich mehr Ressourcen der CPU brach liegen hat (50% vom Frontend liegen brach).

Ich nehme an, Du beziehst Dich auf die Decoder von Zen5, wo bei einem Thread nur einer arbeitet. Dieses Problem von Zen5 ist bei Zen4 nicht vorhanden (der hat nur einen Decoder), und trotzdem ist der Durchsatzzuwachs bei Zen4 deutlich hoeher als bei Willow Cove. Und so schlimm ist das Zen5-Problem nicht (v.a. weil der Code meistens aus dem ucode Cache kommt und nicht ueber die Decoder), schliesslich ist Zen5 auch im single-threaded Betrieb konkurrenzfaehig.

Also irgendwas macht AMD bei SMT besser als Intel. Von daher (und von der hoeheren Effizienz von Intel's E-Kernen) ist es gut erklaerbar, dass Intel dann darauf verzichtet hat, und AMD nicht. Umgekehrt: glaubst Du wirklich, dass Intel SMT weggelassen haette, wenn es viel bringen wuerde?

 

[Piktogramm]

Vor kurzem habe ich gemessen, [...] Das ist schon deutlich schlechter.

Beim Numbercrunching kann SMT nur groß mehr Durchsatz bringen, wenn die CPU ungenutzte Ressourcen hat, die ein zweiter, virtueller CPUthread nutzen kann. Was im Umkehrschluss aber auch bedeutet, dass ein einzelner Thread die entsprechende CPU nicht gut auslasten kann. Das sind Kompromisse, die aller Wahrscheinlichkeit sehr bewusst eingegangen werden bei der Auslegung, bedeutet aber nicht, dass zwingend eine Implementierung (von SMT und allemein) schlecht sein muss.
Zudem: https://chipsandcheese.com/i/149874008/simultaneous-multi-threading-smt
Redwood Coves SMT gibt es als Analyse und auffällig schlecht ist das erstmal nicht. Es Wird mit Zen4 verglichen.

Und so schlimm ist das Zen5-Problem nicht (v.a. weil der Code meistens aus dem ucode Cache kommt und nicht ueber die Decoder), schliesslich ist Zen5 auch im single-threaded Betrieb konkurrenzfaehig. Also irgendwas macht AMD bei SMT besser als Intel.

Ich habe nicht geschrieben, dass es schlimm ist, sondern dass da schlicht viele Ressourcen ungenutzt sind, wenn man da kein SMT verwendet.
Bei Zen4 deutet der große Gewinn von SMT auch darauf hin, dass da Ressourcen von einem CPU-Thread nicht gut ausgenutzt werden.
Bei den Architekturanalysen die es gibt, sind die Implementierungen im Bezug auf Partitionierung von Ressourcen bei Intel und AMD recht vernünftig.

Von daher (und von der hoeheren Effizienz von Intel's E-Kernen) ist es gut erklaerbar, dass Intel dann darauf verzichtet hat, und AMD nicht. Umgekehrt: glaubst Du wirklich, dass Intel SMT weggelassen haette, wenn es viel bringen wuerde?

Ich kann allenfalls mutmaßen. Ich glaube, beide Hersteller mit unterschiedlichen Zielen ihre Architekturen entwickelt haben. Intel mit dem Ziel, dass einen Kern so auszulegen, dass da ein Thread flott läuft und die Architektur dann so schmal auslegen, wie es geht. AMD hingegen wollte ein Design, welches virtuellen Threads sehr schnell laufen können und hat die Architektur an einigen stellen entsprechend breiter ausgelegt.
Andere Ziele, andere Ergebnisse und jeweils nicht zwingend schlechter/besser.

 

[TausendWatt]

was ich noch merkwürdig finde, das core 7 und core 5 die selbe kernzahl haben, gabs das schon mal in der vergangenheit?

JA nur HT war der unterschied.

 

[Piktogramm]

macht das nach unten eine Lücke im Portfolio auf. Dort würde Core-N dann weiterlaufen.

Rein vom Preis ist da Platz, technisch sehe ich da aber wenig. Was soll technisch an 1P4E mit 1x Xe3 an SingleChannel groß beschnitten werden? I/O ist mit 6x PCIe sowieso schon recht schmal und Thunderbolt mit "up to 2x" als optional vermerkt.
Das sich die Lücke vom Preis her ergibt sehe ich eher damit begründet, dass Intels Vorstand gewisse Margen sehen will: https://www.theregister.com/2025/06/04/intel_gross_margin_boost_plan/

 

[uberLemu]

@Piktogramm Ja, ich vermute auch eine rein geschäftliche, keine technische Entscheidung. Vermutlich war mal die vollständige Ablöse von Alder Lake-N / Twin Lake gedacht; allein die Entscheidung für Single Channel legt das imho schon sehr nahe.

 

[mae]

Beim Numbercrunching kann SMT nur groß mehr Durchsatz bringen, wenn die CPU ungenutzte Ressourcen hat, die ein zweiter, virtueller CPUthread nutzen kann. Was im Umkehrschluss aber auch bedeutet, dass ein einzelner Thread die entsprechende CPU nicht gut auslasten kann. Das sind Kompromisse, die aller Wahrscheinlichkeit sehr bewusst eingegangen werden bei der Auslegung, bedeutet aber nicht, dass zwingend eine Implementierung (von SMT und allemein) schlecht sein muss.
Zudem: https://chipsandcheese.com/i/149874008/simultaneous-multi-threading-smt
Redwood Coves SMT gibt es als Analyse und auffällig schlecht ist das erstmal nicht. Es Wird mit Zen4 verglichen.

Klar kann SMT nur dann etwas bringen, wenn die CPU nicht die ganze Zeit von ein und derselben Resource limitiert wird, ob die Anwendung jetzt Numbercrunching ist oder etwas anderes (in meinem Fall habe ich LaTeX gemessen). Was die Messungen von Redwood Cove im Vergleich zu Zen4 betrifft, ist Zen4 schon bei den Messungen mit einem Thread deutlich ueberlegen: Faktor 1.38 bei SPECint2017 und 1.28 bei SPECfp 2017 (wobei ein Laptop- gegen einen Desktop-Chip antritt, aber bei Verwendung eines einzigen Cores sollte das noch nicht so viel ausmachen), und bei zwei Threads auf dem Core steigert sich das auf 1.51 bzw. 1.5. Der SMT-Durchsatz-Faktor ist:

             int  fp
Redwood Cove 1.17 1.04  
        Zen4 1.29 1.21

Also deutlich mehr SMT-Durchsatzzuwachs bei Zen 4.

Zen4 ist schon bei einem Thread deutlich ueberlegen ist, und zwar mehr als der Unterschied der Turbo-Taktrate (19%) ausmacht, die wohl bei so einer Single-Core-Last anliegt; das spricht gegen Deine Theorie, dass Zen4 seine Resourcen im single Thread besonders schlecht nutzt, und der bessere SMT-Speedup nur daher kommt, weil es deswegen leichter ist. Es scheint dagegen umgekehrt so zu sein, dass bei Intel die Resourcen im SMT-Modus nicht so gut genutzt werden koennen wie AMD das schafft.

Hier ein paar Daten vom LaTeX-Benchmark:

                                   cycles                IPC
            instructions      1T            2T         1T   2T
Willow Cove 3_031_678_276 1_264_267_263 2_173_578_644 2.40 1.40
       Zen4 3_562_459_586 1_336_532_240 1_979_287_843 2.67 1.81

Willow Cove ist der Kern von Tiger Lake. Die Anzahl der Befehle bei diesem Benchmark unterscheidet sich, weil das verschiedene Installationen von LaTeX sind (Willow Cove Ubuntu 22.04, Zen4 Debian 12, und die installierten Pakete unterscheiden sich auch). Bei den Zyklen und IPC habe ich immer das bessere von den zwei Threads fuer jeden Prozessor genommen, die Unterschiede zwischen den Threads waren aber gering. Wir sehen, dass der IPC auf Zen4 sowohl in 1T als auch in 2T deutlich hoeher ist. Das koennte man zumindest bei 1T vielleicht noch damit erklaeren, dass die moeglicherweise schlechtere Optimierung bei Debian (mehr instructions) eventuell zu einem guten Teil aus Befehlen besteht, die die nicht auf dem kritischen Pfad sind und daher IPC erhoehen. Aber im 2T-Betrieb sind dann auch die Zyklen deutlich geringer als auf Willow Cove, was sich nicht so leicht wegerklaeren laesst.

Mit einem IPC ueber beide Threads in SMT-Betrieb von 2.8 bei Willow Cove und 3.62 bei Zen4 sind diese Mikroarchitekturen auch noch ein ordentliches Stueck von ihren Limits (5 IPC bei Willow Cove, 6 IPC bei Zen4) entfernt, und bezueglich einzelner functional units (loads, stores, branches, ALUs) ebenfalls. Also beide Mikroarchitekturen nutzen die Resourcen nicht voll aus, Willow Cove ist mit 56% IPC-Nutzung im 2T-Betrieb aber weiter weg von der vollen Nutzung als Zen4 (60%). Bei beiden Mikroarchitekturen scheint es also etwas zu geben, das eine staerkere Nutzung der Resourcen verhindert, und zwar ueber die Abhaengigkeiten hinaus, die wohl der Grund fuer den begrenzten IPC im 1T-Betrieb sind.

Das Ideal waere ja, dass der zweite Thread die ungenutzten Resourcen nutzen kann und das bei der geringen Resourcennutzung des 1T-Betriebs fast ohne Verzoegerung, sodass im 2T-Betrieb jeder Thread fast soviel IPC hat wie im 1T-Betrieb, fuer einem IPC zusammen von knapp unter 4.8 auf Willow Cove und knapp unter 5.34 auf Zen4. Davon sind beide weit entfernt, aber Zen 4 nicht ganz so weit als Willow Cove.

Eine interessante Frage in dem Zusammenhang ist, warum weder Intel noch AMD mehr als zwei SMT-Threads implementiert haben, waehrend Sun/Oracle und IBM 8 Threads pro Kern unterstuetzen. Ich vermute einmal, dass das, was SMT auf Intel und AMD-Prozessoren beschraenkt, sich nicht ohne weiteres entfernen laesst, ohne die 1T-Performance zu reduzieren.

Ich kann allenfalls mutmaßen. Ich glaube, beide Hersteller mit unterschiedlichen Zielen ihre Architekturen entwickelt haben. Intel mit dem Ziel, dass einen Kern so auszulegen, dass da ein Thread flott läuft und die Architektur dann so schmal auslegen, wie es geht. AMD hingegen wollte ein Design, welches virtuellen Threads sehr schnell laufen können und hat die Architektur an einigen stellen entsprechend breiter ausgelegt.

Die P-Kerne von Intel haben in vielerlei Hinsicht mehr Resourcen als Zen*-Kerne von AMD aus derselben Zeit, was sich auch in einer deutlich groesseren Flaeche niederschlaegt (im obigen Fall ist Willow Cove eine Variante von Sunny Cove aus 2019 (wobei Intel das nach dem Tick-Tok-Modell eigentlich schon 2017 haette veroeffentlichen wollen), waehrend Zen4 2022 erschien; der 2022 erschienene Golden Cove kann 6 IPC und hat einen groesseren ROB und groessere Register Files als Zen4). Ist ja auch kein Wunder, die P-Kerne sollen im 1T-Betrieb Baeume ausreissen, waehrend die Zen*-Kerne sowohl die Aufgaben von Intels P- als auch E-Kernen abdecken muessen.

Angesichts der groesseren Resourcen von P-Kernen wie dem Redwood Cove ist es schon bemerkenswert, dass die Zen* beim 1T-IPC oft mithalten koennen. Dass die ihre Resourcen im 1T-Betrieb schlechter ausnutzen als die P-Cores, ist daher unplausibel. Tatsaechlich scheint es so zu sein, dass die P-Cores ihre Resourcen im 2T-Betrieb schlechter ausnutzen als die Zen*-Cores. Warum das so ist, weiss ich nicht. Jedenfalls hat sich Intel dazu entschieden, SMT vorerst abzuschaffen, und die Daten geben eine Erklaerung dafuer.

Was Prozessoren betrifft, die fuer SMT ausgelegt sind, habe ich vor kurzem Power 10 (5GHz) mit Zen 4 (8700G, 5GHz) und Willow Cove (1135G7, 4.2GHz) verglichen. Folgende Ergebnisse sind die Laufzeiten in Sekunden pro Task, um 1-8 Tasks (wieder der LaTeX-Benchmark) auf einem Kern mit (bis auf eine Ausnahme) eingeschaltetem SMT laufen zu lassen. Auf Zen4 und Willow Cove laufen natuerlich nur jeweils zwei Tasks in Hardware-Threads, den Rest macht das OS mit Context-Switching.

               8700G    8700G             
tasks Power10  SMT on   SMT off  1135G7   
1     0.475022 0.270851 0.268371 0.302320 
2     0.475875 0.400696 0.54893  0.529775 
3     0.6817   0.6106   0.84062  0.8004   
4     0.75381  0.82037  1.15060  1.08822  
5     0.9574   1.0358   1.4670   1.3839   
6     1.1182   1.2592   1.7783   1.6785   
7     1.2289   1.4795   2.0997   1.9768   
8     1.31267  1.7060   2.4117   2.33397

Hier sieht man schoen, dass Power 10 bei zwei Tasks noch beide ohne nennenswerte Verzoegerung parallel auf dem Kern laufen lassen kann, aber Zen4 bei einem Task und auch noch bei zwei und drei Tasks schneller ist. Mit 8 Kernen auf dem Kern ist Power 10 dann deutlich schneller. Da zeigt Power 10 genau den Effekt, den Du fuer AMD-Prozessoren angenommen hast.

 

[latiose88]

@mae sehr interessant das ganze. Gehe mal davon aus daß ich das selbe Problem mit einem anderen Programm ebenso habe. Es wird ja immer von IPC Steigerung von Zen 4 auf Zen 5 berichtet. Das blieb teilweise aus.
Gab es von Zen 4 - 8 Kerner wie den 7700x auf Zen 5 - 8 Kerner die Steigerung so wie es angekündigt worden war.
Sieht es bei 12 und 16 Kerner anderst aus.
Wenn zwischen 7950x auf 9950x bei gleichen Takt das selbe Ergebnis dabei raus kommt bei sonst selben Bedingung wie OS und so ,dann limitiert was anderes. Kann ja sein das die letenz die steigerung auffrisst und so die Leistung am Ende nicht zu der Anwendung an. Also ist es möglich das ich auch eine latentz die Leistung sabotiert oder limitiert oder gibt es dazu noch andere Sachen die Schuld dran sind ?

Bei Intel habe ich es bisher noch nicht feststellen können. Würdest du dir Gedanken machen wenn fast die selbe Takt bei 20 Kernen auch wenn es p und e Kerne sind es mit gleichen Takt gegen einen 9950x mit normalen Taktraten ebenbürtig ist obwohl eigentlich der mit mehr Kernen der sieger ist und erst bei höheren Taktraten gewinnt der 9950x deutlich ? Und beeinflusst Takt die Latenz erheblich ?

 

[mae]

Also ist es möglich das ich auch eine latentz die Leistung sabotiert oder limitiert oder gibt es dazu noch andere Sachen die Schuld dran sind ?

Natuerlich ist das moeglich. Ein pointer-chasing-Programm (ein load wartet auf das Resultat des vorherigen) wird auf Zen5 nicht schneller laufen also auf Zen4 (auch auf einem Kern nicht), weil die Latenzen und Cache-Groessen dieselben sind. In der Praxis gibt's halt auch Programmteile, die mehr von Resourcen als von Latenzen dominiert sind, dann bringen die zusaetzlichen Resourcen auf Zen5 natuerlich schon einen Vorteil.

Würdest du dir Gedanken machen wenn fast die selbe Takt bei 20 Kernen auch wenn es p und e Kerne sind es mit gleichen Takt gegen einen 9950x mit normalen Taktraten ebenbürtig ist obwohl eigentlich der mit mehr Kernen der sieger ist und erst bei höheren Taktraten gewinnt der 9950x deutlich ?

Wenn ich die Performance eines Prozessors verstehen will, mache ich mir natuerlich Gedanken, ueber alles Moegliche. Wenn nicht, nicht.

Und beeinflusst Takt die Latenz erheblich ?

1) Wenn ein Prozessor fuer niedrigeren Takt ausgelegt ist, sind die Latenzen der functional units in Zyklen (meist nicht in Zeit) in manchen Faellen geringer, vergleiche z.B. die D-Cache-Latenz von Apple-Prozessoren mit der von AMD-Prozessoren.

2) Wenn ein Prozessor auf etwas ausserhalb seiner Taktdomaene zugreift (z.B. auf Hauptspeicher), dann sieht der Prozessor mehr Zyklen (nicht mehr Zeit) Latenz, wenn er hoeher taktet als wenn er niedriger taktet; das gilt sowohl fuer die dynamische Taktung (Turbo und so) als auch fuer Prozessoren mit begrenztem Takt (z.B. Zen5 im Desktop vs. im Server).

 

[Piktogramm]

Klar kann SMT nur dann etwas bringen, wenn die CPU nicht die ganze Zeit von ein und derselben Resource limitiert wird, ob die Anwendung jetzt Numbercrunching ist oder etwas anderes (in meinem Fall habe ich LaTeX gemessen).

Latex baut bzw. durchschreitet Bäume, bei den kleinen Testgrößen bei dir, die unter mit unter 1s Laufzeit ist das dann vor allem ein Test wie gut die Sprungvorhersage ist, wie gering die Latenz der Caches sind und aller Techniken hier helfen (Prefetch, große Rob, ..).
Und jenachdem wie die Zeitnahme erfolgt, bencht man das Betriebssystem mit und dessen Geschwindigkeit Prozesse zu handhaben, wenn man Tasks hat, die deutlich unter 1s laufen.

Was die Messungen von Redwood Cove im Vergleich zu Zen4 betrifft, ist Zen4 schon bei den Messungen mit einem Thread deutlich ueberlegen: Faktor 1.38 bei SPECint2017 und 1.28 bei SPECfp 2017 (wobei ein Laptop- gegen einen Desktop-Chip antritt, aber bei Verwendung eines einzigen Cores sollte das noch nicht so viel ausmachen),

Zen 1..5 sind jeweils recht gute Architekturen, das wirst du von mir kaum anders hören. Genauso wie ich die neueren Intel Architekturen recht gut finde.

Zen4 ist schon bei einem Thread deutlich ueberlegen ist, und zwar mehr als der Unterschied der Turbo-Taktrate (19%) ausmacht, die wohl bei so einer Single-Core-Last anliegt; das spricht gegen Deine Theorie, dass Zen4 seine Resourcen im single Thread besonders schlecht nutzt, und der bessere SMT-Speedup nur daher kommt, weil es deswegen leichter ist. Es scheint dagegen umgekehrt so zu sein, dass bei Intel die Resourcen im SMT-Modus nicht so gut genutzt werden koennen wie AMD das schafft.

Meine Aussage war, Zen4/5 hat bei Nutzung eines Threads ungenutzte Ressourcen hat, was in meinen Augen ein schlechte Nutzung der Ressourcen ist, aber ich vermute, dass das eine bewusste Entscheidung seitens AMD war um virtuelle Threads mit höherem Durchsatz zu ermöglichen.

Willow Cove ist der Kern von Tiger Lake. Die Anzahl der Befehle bei diesem Benchmark unterscheidet sich, weil das verschiedene Installationen von LaTeX sind (Willow Cove Ubuntu 22.04, Zen4 Debian 12, und die installierten Pakete unterscheiden sich auch). Bei den Zyklen und IPC habe ich immer das bessere von den zwei Threads fuer jeden Prozessor genommen, die Unterschiede zwischen den Threads waren aber gering.
Wir sehen, dass der IPC auf Zen4 sowohl in 1T als auch in 2T deutlich hoeher ist. Das koennte man zumindest bei 1T vielleicht noch damit erklaeren, dass die moeglicherweise schlechtere Optimierung bei Debian (mehr instructions) eventuell zu einem guten Teil aus Befehlen besteht, die die nicht auf dem kritischen Pfad sind und daher IPC erhoehen. Aber im 2T-Betrieb sind dann auch die Zyklen deutlich geringer als auf Willow Cove, was sich nicht so leicht wegerklaeren laesst.

Benchmarks mit unterschiedlichem Code.. Ich werd mich nicht dran aufhängen .
Nur bedeuten weniger/mehr Instruktionen nicht immer schlechteres Laufzeitverhalten. Kleine Schleifen (wenig Iterationen) auflösen bringt mehr Instruktionen, mitunter aber mehr Geschwindigkeit.

Mit einem IPC ueber beide Threads in SMT-Betrieb von 2.8 bei Willow Cove und 3.62 bei Zen4 sind diese Mikroarchitekturen auch noch ein ordentliches Stueck von ihren Limits (5 IPC bei Willow Cove, 6 IPC bei Zen4) entfernt, und bezueglich einzelner functional units (loads, stores, branches, ALUs) ebenfalls. Also beide Mikroarchitekturen nutzen die Resourcen nicht voll aus, Willow Cove ist mit 56% IPC-Nutzung im 2T-Betrieb aber weiter weg von der vollen Nutzung als Zen4 (60%). Bei beiden Mikroarchitekturen scheint es also etwas zu geben, das eine staerkere Nutzung der Resourcen verhindert, und zwar ueber die Abhaengigkeiten hinaus, die wohl der Grund fuer den begrenzten IPC im 1T-Betrieb sind.

Wie anfangs beschrieben. Latex baut (Abhänigkeits-)Bäume und durchschreitet diese. Da wird es immer wieder Stalls geben.

Das Ideal waere ja, dass der zweite Thread die ungenutzten Resourcen nutzen kann und das bei der geringen Resourcennutzung des 1T-Betriebs fast ohne Verzoegerung, sodass im 2T-Betrieb jeder Thread fast soviel IPC hat wie im 1T-Betrieb.

Dein Ideal kann nur erreicht werden, wenn es keinerlei Konkurrenz um Ressourcen zwischen den Threads gäbe, was unwahrscheinlich ist, wenn die Threads annähernd das Selbe Problem lösen sollen, also die selben Funktionseinheiten nutzen wollen. Also entweder baut man quasi zwei Kerne, damit die Threads exklusiv nutzen können oder baut sehr primitives, statisch partitioniertes bzw. statisch gemuxtes SMT zu Lasten von singlethread. Da würde ich dann der Aussage, dass das eine schlechte Implementierung von SMT ist mitgehen (zumindest für 0815 CPU Designs ohne Spezialisierung). Sobald es Konkurrenz um die Ressourcen gibt und das ganze auch nur in Teilen dynamisch verwaltet wird, kann dein Ideal nie erfüllt werden.

Eine interessante Frage in dem Zusammenhang ist, warum weder Intel noch AMD mehr als zwei SMT-Threads implementiert haben, waehrend Sun/Oracle und IBM 8 Threads pro Kern unterstuetzen. Ich vermute einmal, dass das, was SMT auf Intel und AMD-Prozessoren beschraenkt, sich nicht ohne weiteres entfernen laesst, ohne die 1T-Performance zu reduzieren.

8fach SMT lohnt bei besagten vor allem, da diese Prozessoren sehr eng umfasste Aufgaben sehen werden. Irgendwas mit vielen aktiven Prozessen, die von Stalls geplagt sind. Wobei die Kunden oftmals "lustige" Software einsetzen, die nach Anzahl der physischen Prozessorkernen (Kernen) lizenziert ist. Hier bringt ein hoher Grad an virtuellen CPU-Threads viel.

Die P-Kerne von Intel haben in vielerlei Hinsicht mehr Resourcen als Zen*-Kerne von AMD aus derselben Zeit, was sich auch in einer deutlich groesseren Flaeche niederschlaegt [...]

Angesichts der groesseren Resourcen von P-Kernen wie dem Redwood Cove ist es schon bemerkenswert, dass die Zen* beim 1T-IPC oft mithalten koennen. Dass die ihre Resourcen im 1T-Betrieb schlechter ausnutzen als die P-Cores, ist daher unplausibel.

Skalierung mit SMT geht nur bei freien Ressourcen. Freie Ressourcen für SMT bedeuten immer auch, dass ohne SMT Ressourcen nicht voll ausgenutzt werden. Ich wiederhole dabei aber auch, dass kann eine bewusste Designentscheidung und muss nichts Schlechtes sein. Es ist aber definitiv kein Anzeichen dafür, dass die Implementierung von SMT bei Konkurrenten schlecht sein muss im Vergleich, auch wenn diese schlechter mit SMT skaliert.

Und beim Vergleich von Redwood zu Zen4 bei Chips and Cheese. Beide sind vom FrontEnd zum Backend 6µOps breit, und die Anzahl der Executionports für Int, FP/Vec, Ld/St sind vergleichbar. Grundlegend sehe ich da keinen gewaltigen Unterschied in der Breite beider Architekturen.
Auch bei den Registerfiles und deren Aufteilung für SMT, sind das keine extremen Differenzen.
Einzig, dass Zen4 mit 4EPs für FP/Vec breiter ausgelegt ist als Redwood (3 EPs).

Tatsaechlich scheint es so zu sein, dass die P-Cores ihre Resourcen im 2T-Betrieb schlechter ausnutzen als die Zen*-Cores. Warum das so ist, weiss ich nicht. Jedenfalls hat sich Intel dazu entschieden, SMT vorerst abzuschaffen, und die Daten geben eine Erklaerung dafuer.

Imho ist das eine Umkehr der Kausalitäten. Intel hat zuletzt Designs gebaut die mit SMT nicht gut skalieren bis zu einem Punkt, wo es kaum mehr Sinn macht SMT überhaupt anzubieten. Wobei die mangelnde Skalierung das Ergebnis der Zielsetzung war für flottes ST mit sinnvoll kompakten Designs. Wenn du dir die Tabelle von Chips and Cheese anschaust. Da ist kein grober Patzer was so grundlegende Gesichtspunkte für eine gute SMT-Implementierung angeht.
Ich halte die Ingenieure bei Intel für fähig, die werden nicht hunderte Millionen an Entwicklung verpulvert haben um festzustellen, dass "zufällig" ihre SMT-Implementierung kaum mehr Gewinne liefert.

Was Prozessoren betrifft, die fuer SMT ausgelegt sind, habe ich vor kurzem Power 10 (5GHz) mit Zen 4 (8700G, 5GHz) und Willow Cove (1135G7, 4.2GHz) verglichen. Folgende Ergebnisse sind die Laufzeiten in Sekunden pro Task, um 1-8 Tasks (wieder der LaTeX-Benchmark) auf einem Kern mit (bis auf eine Ausnahme) eingeschaltetem SMT laufen zu lassen. Auf Zen4 und Willow Cove laufen natuerlich nur jeweils zwei Tasks in Hardware-Threads, den Rest macht das OS mit Context-Switching.
<Tabelle>
Hier sieht man schoen, dass Power 10 bei zwei Tasks noch beide ohne nennenswerte Verzoegerung parallel auf dem Kern laufen lassen kann, aber Zen4 bei einem Task und auch noch bei zwei und drei Tasks schneller ist. Mit 8 Kernen auf dem Kern ist Power 10 dann deutlich schneller. Da zeigt Power 10 genau den Effekt, den Du fuer AMD-Prozessoren angenommen hast.

Ich nehme das bei AMD immer noch an, halte es aber für Absicht. Ebenso wie beim Power10

 

[mae]

Ich habe jetzt Zugriff auf einen Core i3-1315U (wohl ein Golden Cove P-Core, jedenfalle 6 Befehle/Zyklus breit und damit in dieser Hinsicht vergleichbar zu Zen4 und wohl sehr nahe an Redwood Cove), unter Ubuntu 22.04 laufend, und habe einige der Tests wiederholt.

                                   cycles                IPC
            instructions      1T            2T         1T   2T
Willow Cove 3_031_678_276 1_264_267_263 2_173_578_644 2.40 1.40
Golden Cove 2_654_776_800   891_787_049 1_491_438_900 2.98 1.78
       Zen4 3_562_459_586 1_336_532_240 1_979_287_843 2.67 1.81

Auf dem System mit dem Golden Cove sind weniger Pakete installiert als auf dem mit dem Willow Cove, daher der Unterschied bei den instructions. Wenn wir annehmen, dass das fuer IPC und SMT keine Auswirkungen hat (tatsaechlich deuten fruehere Resultate darauf hin, dass das Bearbeiten der zusaetzlichen Pakete eine geringere IPC hat als die Grundfunktionalitaet), dann wuerde Golden Cove seine Resourcen im 1T-Betrieb besser nutzen (50%) und im SMT-Betrieb ein bisschen schlechter (59%) als Zen4, mit einem Durchsatzzuwachsfaktor von 1.20, im Vergleich zu Faktor 1.35 bei Zen4. Beides ist etwas hoeher als der jeweilige Zuwachs bei SPECint 2017. Wenn man beruecksichtigt, dass beim Golden Cove mit mehr LaTeX-Paketen die IPC vielleicht noch leiden wuerde, wuerde er in 1T-Betrieb vielleicht aehnlich viel IPC haben wie Zen4 und im 2T-Betrieb dann in IPC deutlicher unterlegen sein; aber das ist Spekulation.

Hier noch die Laufzeiten mit bis zu je 8 Tasks auf einem einzigen Kern:

               8700G    8700G             
tasks Power10  SMT on   SMT off  1135G7   1315U
1     0.475022 0.270851 0.268371 0.302320 0.2355618
2     0.475875 0.400696 0.54893  0.529775 0.393541
3     0.6817   0.6106   0.84062  0.8004   0.5935
4     0.75381  0.82037  1.15060  1.08822  0.79786
5     0.9574   1.0358   1.4670   1.3839   0.99878
6     1.1182   1.2592   1.7783   1.6785   1.20673
7     1.2289   1.4795   2.0997   1.9768   1.41565
8     1.31267  1.7060   2.4117   2.33397  1.62407

Latex baut bzw. durchschreitet Bäume, bei den kleinen Testgrößen bei dir, die unter mit unter 1s Laufzeit ist das dann vor allem ein Test wie gut die Sprungvorhersage ist

Die Sprungvorhersage ist bei diesen Prozessoren fuer diesen Benchmark recht gut. Z.B. hat der Golden Cove ca. 1% mispredictions, oder 1.77 MPKI (mispredictions per 1000 instructions) im 1T-Betrieb.

wie gering die Latenz der Caches sind und aller Techniken hier helfen (Prefetch, große Rob, ..).

Der Benchmark hat wenig D-cache-misses (0.8%, bzw. 2.42 D-cache-misses/1000 instructions auf Golden Cove). Die Latenz des L1 caches ist bei den obigen Intel-Prozessoren mit 5 Zyklen etwas hoeher als bei Zen4 mit 4 Zyklen. Scheint aber beim 1T-IPC nicht besonders zu stoeren.

Und jenachdem wie die Zeitnahme erfolgt, bencht man das Betriebssystem mit und dessen Geschwindigkeit Prozesse zu handhaben, wenn man Tasks hat, die deutlich unter 1s laufen.

Das ist nicht Windows, ein einfacher Prozess wie /bin/true braucht weniger als 1M Zyklen und 0.001437819s elapsed time. Insofern ist der Einfluss des Prozessoverheads bei diesem Benchmark nicht besonders gross. Von den Zyklen werden 29M im Kernel verbracht und 862M im user mode, der Einfluss des Betriebssystems sollte also gering sein.

Meine Aussage war, Zen4/5 hat bei Nutzung eines Threads ungenutzte Ressourcen hat, was in meinen Augen ein schlechte Nutzung der Ressourcen ist, aber ich vermute, dass das eine bewusste Entscheidung seitens AMD war um virtuelle Threads mit höherem Durchsatz zu ermöglichen.

Auch Willow und Golden Cove haben im 1T-Betrieb ungenutzte Resourcen: 52% ungenutzt in Willow Cove und 50% ungenutzt in Golden Cove. Das liegt aber nicht an bewussten Entscheidungen fuer SMT; im Gegenteil, beide Hersteller versuchen alles, um 1T-Koenige zu sein. Der Grund fuer die geringe Resourcennutzung ist fuer verschiedene Programme unterschiedlich, dafuer hat Intel daher TMA (top-down microarchitectural analysis) entwickelt. Auf der obersten Ebene sagt das fuer diesen LaTeX-Benchmark (1T auf Golden Cove):

10.5 %  tma_backend_bound      
14.3 %  tma_bad_speculation    
25.3 %  tma_frontend_bound     
49.8 %  tma_retiring

Die 49.8% retiring sind die nuetzlichen Befehlsslots. Die restlichen 50.2% teilen sich in 25.3% auf, die im Front end verloren gingen, 14.3%, die in Mispreductions verloren gingen (obwohl die misprediction-Rate so niedrig ist), und 10.5%, bei denen es irgendwo im Backend stockt. Jetzt kann man bei TMA die Einzelaspekte genauer betrachten, aber das mache ich vielleicht ein andermal.

Benchmarks mit unterschiedlichem Code..

Der Aufwand, den ich in ein Posting stecke, ist nun einmal geringer als bei einem Paper fuer eine grosse Konferenz.

Nur bedeuten weniger/mehr Instruktionen nicht immer schlechteres Laufzeitverhalten. Kleine Schleifen (wenig Iterationen) auflösen bringt mehr Instruktionen, mitunter aber mehr Geschwindigkeit.

Die hier genannten Befehle sind die dynamisch ausgefuehrten, nicht die statische Programmgroesse. Loop unrolling reduziert die dynamisch ausgefuehrten Befehle ueblicherweise, auch wenn es die statische Programmgroesse erhoeht.

Dein Ideal kann nur erreicht werden, wenn es keinerlei Konkurrenz um Ressourcen zwischen den Threads gäbe, was unwahrscheinlich ist, wenn die Threads annähernd das Selbe Problem lösen sollen, also die selben Funktionseinheiten nutzen wollen.

Da im 1T-Betrieb von den oben genannten Prozessoren weniger als 50% der knappsten Resource (renamer slots) genutzt werden, waere eine Verdopplung des Durchsatzes im 2T-Betrieb zumindest theoretisch moeglich.

Du scheinst von der Idee auszugehen, dass die Ausfuehrungsgeschwindigkeit von Programmen durch die Resourcen begrenzt ist. Das ist bei vielen Programmen nicht bzw. nur in einzelnen Zyklen der Fall. Z.B. warten Befehle oft auf Ergebnisse von anderen Befehlen statt auf Resourcen zu warten. Der LaTeX-Benchmark koennte so ein Fall sein, aber dazu muesste man sich das im TMA genauer anschauen, und selbst da bleiben bei mir am Ende oft Fragezeichen uebrig.

Aber nehmen wir einen einfachen Fall: Ein pointer-chaser, der sonst nichts macht (also nur ein load nach dem anderen, jedes load abhaengig vom Resultat des vorigen, und vielleicht alle 100 Befehle ein Schleifenruecksprung), und der trifft immer in den L1 cache. Der fuehrt auf Zen4 0.25IPC aus (bzw. ein bisschen mehr, weil der Ruecksprung parallel ist), und auf Willow und Golden Cove 0.2IPC. Ein zweiter solcher Thread wuerde genau dieselben resourcen ansprechen, sollte aber theoretisch problemlos mit dem selben IPC im zweiten Thread laufen koennen, weil er eben von 2 (oder waren es 3?) load units dieser Prozessoren nur eine braucht, und zwar einmal alle 4 bzw. 5 Zyklen. Aber ich werde das auch nicht jetzt messen, wie gut diese Prozessoren sowas in SMT tatsaechlich koennen; es geht ja auch nur darum, zu zeigen, dass Programme im 1T-Betrieb nicht unbedingt (und allgemein eher selten) von den resourcen begrenzt werden. Deswegen hat man ja SMT eingefuehrt.

Imho ist das eine Umkehr der Kausalitäten. Intel hat zuletzt Designs gebaut die mit SMT nicht gut skalieren bis zu einem Punkt, wo es kaum mehr Sinn macht SMT überhaupt anzubieten. Wobei die mangelnde Skalierung das Ergebnis der Zielsetzung war für flottes ST mit sinnvoll kompakten Designs. Wenn du dir die Tabelle von Chips and Cheese anschaust. Da ist kein grober Patzer was so grundlegende Gesichtspunkte für eine gute SMT-Implementierung angeht.
Ich halte die Ingenieure bei Intel für fähig, die werden nicht hunderte Millionen an Entwicklung verpulvert haben um festzustellen, dass "zufällig" ihre SMT-Implementierung kaum mehr Gewinne liefert.

Klar sind die faehig, und sie haben als primaeres Ziel 1T-Performance, wie die bei AMD. Bei beiden ist SMT nur Beiwerk, das vermutlich keine hunderte Millionen gekostet hat, wo aber vor allem wichtig war, die 1T-Performance nicht zu beeintraechtigen und keine Verzoegerungen im Zeitplan zu verursachen. Bei AMD ist SMT besser gelungen, aber richtig gut ist etwas anderes. Und bei Intel ist SMT nicht erst "zuletzt" schwach, das habe ich z.B. schon 2016 bei Skylake auf dem LaTeX-Benchmark gesehen. Dass Intel es zuletzt rausgeworfen hat, hat m.E. mit den E-Cores zu tun. Und im Multi-Core-Betrieb kann Arrow Lake WIMRE auch ueberzeugen, der braucht SMT also tatsaechlich nicht.

Dass dann irgendwelche Server-Kunden sagen, sie wollen lieber P-Core-Xeons, die aber mit SMT, als E-Core-Xeons, ist Bloedheit der Kunden, denen Intel offenbar lang genug eingeredet hat, wie toll doch "Hyperthreading" sei, dass jetzt fest daran glauben. Jetzt rudert Intel wieder zurueck; ich schaetze einmal, bis die wieder P-Core-Xeons mit SMT haben, haben es die Kunden verstanden, dass sie entweder starke Cores (P-Cores ohne SMT) oder viele Cores (E-Cores) brauchen. Aber naja, wird wohl nicht so auffallen, wenn SMT dann wenig genutzt wird.