News Intel Core Ultra 200S im Detail: IPC-Analyse der P- und E-Cores vs. Raptor Lake und Zen 5

@Jan habe ich es überlesen (auch im Hauptthread), oder wurde nicht untersucht, wegen E Cores und Games?
Danke
 
Abrexxes schrieb:
Müsste das nicht eher "Befehle/Anweisungen pro Takt" sein?
Ja und Nein. Instructions per Clock ist ein etwas "dehnbarer" Begriff, weil es keine einheitliche Messmethode gibt.

Sieht man sich Zen 5 an, dann kann Zen 5 theoretisch 16 Befehle zur gleichen Zeit ausführen, bei Lion Cove sind es bis zu 18 Befehle. Davon sind aber manche "INT", andere "VEC" und wieder andere Load/Store-Anweisungen.

Deswegen ging man mit der Zeit über, die IPC anhand von Programmen zu ermitteln, in denen kommen aber die Befehle in unterschiedlichen Schwerpunkten zum Tragen. Man kann mit dem gleichen Programm aber zwischen verschiedenen Architekturen unterscheiden und der IPC-Begriff hat sich mit der Zeit dafür durchtgesetzt.
Sweepi schrieb:
In einem Bereich liegt Intel gleichauf bis leicht vorne: Kompilieren von Source code.
Die viel besseren E-Cores schlagen da voll durch.
Die E-Cores kommen durch, gleichzeitig ist das aber auch zum Teil dennoch ernüchternd.
Bierliebhaber schrieb:
Puh, also dass die P-Cores quasi gar nicht effizienter geworden sind ist heftig
Ja und Nein, es kommt auf die Betrachtung an. In dem Fall hier wurden ein nT-Test mit allen Prozessoren durchgeführt und die Leistung der einzelnen Kerne ermittelt.

Wenn man jetzt 1T-Tests gegeneinender stellen würde, ist Lion Cove effizienter und schneller als Raptor Cove. Das zeigt die Grafik auch.

Im 1T ist Lion Cove schneller als Redwood Cove und Raptor Cove, Zen 5 liegt quasi gleich auf. Es zeigt sich aber auch, dass Lion Cove, Raptor Cove als auch Zen 5 in der Regel durch 1T nicht wirklich ausgelastet werden und Rechenleistung brach liegt,
 
  • Gefällt mir
Reaktionen: nyster, yummycandy, Zagrthos und eine weitere Person
Einfach Interessant zu welch einmaligen Erkentnissen Intel immer wieder kommt.

Hyper-Threading oder SMT oder sämtliche Pendants sind ursprünglich entwickelt worden, weil es in den Pipelines der Kerne selbst immer wieder gehörige "Lücken" gibt, da auf Zwischenergebnisse, Instruktionen etc. gewartet werden muss. HT/SMT legt im Prinzip eine zweite Pipeline in die Erste, welche autark innerhalb der Lücken betrieben wird. Eben mit Aufgaben oder Instruktionen die unabhängig von der ersten Verarbeitungskette bereits ausgeführt werden können. Die Lücken werden gefüllt und der Kern viel effizienter ausgelastet.

Dies geschieht in der Regel über im CPU Die vorhandene Sheduler, welcher dann dem OS zwei virtuelle Kerne, statt einem physischen bereit stellt.


Nun gibt es zwei Möglichkeiten:

  1. Intel hat den einen ultimativen Weg gefunden, eine x86-CPU bei allen möglichen Instruktionen und Aufgaben die auf sie treffen könnten, so auszulasten, dass keine Lücken entstehen können. Was eigtl schon rein mathematisch komplett unmöglich ist,

    oder aber, natürlich sehr unwahrscheinlich

  2. Intel wollte bei der sowieso schon relativ komplizierten P/E Architektur, Kosten für teure TSMC-DIE Fläche einsparen in dem sie keinen Sheduler verbauen müssen, der zwischen P¹,P² E¹,E² vernünftig aufteilen kann. Anschließend erzählt einem die Marketingabteilung, dass man HT bei x86 ja gar nicht mehr benötige.
Mag sich jetzt jeder selber denken was der Fall ist. Kleine Hinweise gibt es allerdings:

[...]Core Ultra auf den P-Cores bei gleichem Takt [...] -18% fehlen ihm bei 4,0 GHz zum Vorgänger, -23 Prozent (IPC) zum Ryzen 9 9950X.

Hat natürlich nichts mit fehlendem HT/SMT zu tun, denn Intel hat ja bekanntlich gesagt, dass man das nun gar nicht mehr braucht.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Unti, Tharan, baizer und 10 andere
K3ks schrieb:
Soweit mir bekannt: Ja, aber der Cache der c-cores ist wohl auch ordentlich beschnitten.
Jein. Nur L1/L2 sind Teil des Cores, bleiben aber unverändert. L3 gehört bei AMD zum Uncore-Bereich. Es stimmt aber, dass AMD bislang allen c-Cores weniger L3-Cache zur Verfügung stellt als den Standard-Cores. Dadurch liegt bei allen verfügbaren Chips mit Zen 5c (Turin und Strix Point) die IPC dieser Kerne etwas unterhalb der Zen 5 Kerne.

Es ist aber durchaus denkbar, dass noch Produkte kommen, bei denen es da keinen Unterschied macht (Krackan könnte im Gegensatz zu Strix wieder auf einen CCX mit gemeinsamen L3 für alle Kerne setzen, so wie wir es bei Phoenix2 schon mit Zen 4(c) gesehen haben).
Ergänzung ()

Sun_set_1 schrieb:
Intel wollte bei der sowieso schon relativ komplizierten P/E Architektur, kosten für teure TSMC-DIE Fläche einsparen in dem sie keinen Sheduler verbauen müssen, der zwischen P¹,P² E¹,E² vernünftig aufteilen kann
Plausibel, dass es am Scheduling und Problemen damit liegt. Es sei nur angemerkt, dass die E-Cores nie HT unterstützt haben, man also "nur" P¹, P² und E sinnvoll schedulen müsste.
 
  • Gefällt mir
Reaktionen: nyster
DevPandi schrieb:
Damit lässt sich aber auch ableiten, dass der Verzicht auf SMT/HT bei Arrow Lake vielleicht garnicht so geplant war, wie Intel es andeutet - im Serverbereich bei den Lion Coves wird es SMT ja geben.
Allerdings taucht bislang auf keiner Intel Roadmap eine Server CPU mit Lion Cove Kernen auf. Bei den Granite Rapids Xeon Nachfolgern Diamond Rapids Xeon hat Intel Panther Cove-X Kerne (P-Kerne) angegeben, und zwischen Granite Rapids u. Diamond Rapid sind keine Xeon CPUs mit P-Kernen auf Intels CPU Roadmap.
 
  • Gefällt mir
Reaktionen: nyster
stefan92x schrieb:
Plausibel, dass es am Scheduling und Problemen damit liegt. Es sei nur angemerkt, dass die E-Cores nie HT unterstützt haben, man also "nur" P¹, P² und E sinnvoll schedulen müsste.

Du sparst dir halt die komplette DIE-Fläche für den internen Sheduler, welcher dem OS die beiden virtuellen Kerne bereitstellt. Und das natürlich für die P- und für die E-Cores. Das wird schon ein bisl was an Fläche sein.

Bin allerdings auf Intels Marketing gespannt wenn sie in zwei oder drei Generationen von jetzt wieder eine zweite Rechenpipeline einführen, die dann natürlich nicht mehr Hyper-Threading heißen wird.
 
  • Gefällt mir
Reaktionen: nyster
Sweepi schrieb:
Kompilieren von Source code.
Die viel besseren E-Cores schlagen da voll durch.
Im Vergleich zum Intel Vorgänger ja (naja, etwas), aber im Vergleich zu den 16 physischen Kernen des AMD 9950x können die 24 Kerne des 285K nicht wirklich glänzen.
 
  • Gefällt mir
Reaktionen: Casillas, nyster, Sherman789 und eine weitere Person
Schön das AMD beim alten bleibt C+T ich will keine kastrierten Cores ohne HT/SMT. Intel macht das auch nur weil sie den Verbrauch nicht in Griff bekommen.

Ja AMD hat auch so was, aber zum Glück hat man hier wenigstens eine Wahl. Diese Smartphoneartigen Gold/Silver Coregedöns konnte ich beim PC noch nie leiden, werde ich so lange es geht auch nie kaufen.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Fritzler und boypac007
K3ks schrieb:
Ich hab auch Gemunkel gelesen wo HT/SMT o.ä. teilw. zu Sicherheitslücken geführt haben und mitunter deshalb hat Intel vlt. den Kram auch entfernt, who knows. 🤷


Ja und Nein. Zumeist handelt es sich dabei um eigentliche Lücken in der Branch-Prediction. Also dem Bereich in dem eine CPU versucht hervorzusagen, welcher (virtuelle)-Kern als nächstes welche Aufgaben ausführen muss. Branch Prediction findet aber auch statt, wenn es kein HT/SMT gibt.
 
@lynx007 @DevPandi

"Core Ultra 200" ist overall ein ziemlicher Unfall, mit interessanten Details, wie die sehr gute Effizienz (in CB MC) bei 45 - 90 W TDP und der guten Compiler-Performance.
Macht einen eventuellen Core Ultra 300 mit 24/32 E-Cores sehr spannend.

Und ja: wenn einer von den Developer-Kollegen Intel haben will, liegt er jetzt weniger falsch als vorher.
 
  • Gefällt mir
Reaktionen: ILoveShooter132, Fritzler und lynx007
Bei dem Leistungszuwachs der E-Cores würde ich mich über einen Intel N100 Nachfolger sehr freuen.
 
  • Gefällt mir
Reaktionen: M11E, Engaged, Zwirbelkatz und 7 andere
Alesis schrieb:
Eine aktuell 330€ CPU für einen Büro PC? Meinst du das ernst?
https://www.dell.com/de-de/shop/des...-plus-micro/s005o7020mffp_vp?ref=variantstack
https://www.dell.com/de-de/shop/des...plus-desktop/s006o7020mtp_vp?ref=variantstack
https://www.hp.com/de-de/shop/product.aspx?id=A0YY2EA&opt=ABD&sel=DTP

Sind jetzt Beispiele, in denen ein i7 14700 drinnen ist/ausgewählt werden kann, dessen Straßenpreis auch etwa so hoch ist. Ist außerdem auch in meinem Bürorechner drinnen. Wäre also kein großes Ding. Einzig, im Bürorechner ist eher keine K Version drinnen.
 
  • Gefällt mir
Reaktionen: chaopanda und Simanova
Einerseits, ist es dafür nicht noch zu früh? Die Plattform hat defintiv Probleme und die Leistung wird noch minimal steigen.
Andererseits nur Cinebench? Läuft halt nur im Cache. Gute für den Core, schlecht für einen Plattform Test
 
Die Frage ist doch was Intel eigentlich erreichen wollte und wo es schiefgegangen ist. Für mich ist das Ding ganz klar ein Ableger aus dem Mobilbereich der dann "verwurstet" wurde.
 
@CCIBS: Die verlinkten Kisten sind zu teuer und oversized für eine Office-Kiste, dafür reicht auch eine CPU wie 5600g oder 12400 für Richtung 100€-150€ ganz locker um eine sehr potente Office-Kiste zu basteln, vermutlich tut es für die meisten Leute auch ein 12100 oder kleiner... Bei Workstation-Aufgaben dann halt die dickeren CPU-Klopper.
 
  • Gefällt mir
Reaktionen: boypac007 und nyster
Ich verstehe nicht warum man so eine CPU auf den Markt wirft, ein angepasster 14900K mit der Fertigung bei TSMC und fertig wäre der 15900k dann mit L4 Cache und das ding hätte alles weggebrannt.

Mir ist schon klar das es nicht so einfach ist wegen Design usw. aber der 285k ist ein Rohrkrepierer und den hätte ich so niemals gebracht.

Warum fährt man nicht zweigleisig ja kosten bli bla blub aber so die Flinte ins Korn werfen...

Egal freue mich auf AM5, AMD macht zur Zeit fast alles richtig.
 
  • Gefällt mir
Reaktionen: boypac007
Sweepi schrieb:
Und ja: wenn einer von den Developer-Kollegen Intel haben will, liegt er jetzt weniger falsch als vorher.
Sowas seh ich recht entspannt. Bei mir bekommen die Kollegen, was sie wollen, sofern die "Standardrechner" nicht reichen. Nur das müssen sie auch gut begründen. :)
Ergänzung ()

Zock schrieb:
Ich verstehe nicht warum man so eine CPU auf den Markt wirft, ein angepasster 14900K mit der Fertigung bei TSMC und fertig wäre der 15900k dann mit L4 Cache und das ding hätte alles weggebrannt.
Die Frage ist, ob der 14900K mit TSMC N3 auch den Takt hätte halten können oder mehr Takt drin gewesen wäre.
 
Zurück
Oben