Nova Lake-S: Erneut werden bis zu 52 Kerne gemeldet

[IronAge]

I'm not so updated on Nova Lake, but as far as i understand it, it will consist of two compute dies with 8P+16E cores each.
Basically 8P16E + 8P16E + 4E on soc for a total of 52 cores

 

[Holt]

Hoffe mal das Statement war quasi nur aus Trotz und sie kommen wenigstens gut in die Nähe der x3d's.

Es gibt Gerüchte um eine Cache im Base Tile, der sich Local Cache nennt und wohl erstmal nur in den Clearwater Forest Xeons kommen wird, aber zumindest noch nicht für die Desktop CPUs gedacht ist. Schade, denn eigentlich hat ja Intel dies Konzept damals mit den Desktop Broadwell CPUs in Form des eDRAMs eingeführt, der zwar primär für die IGPU gedacht war aber auch als L4 Cache für die CPU dient und den CPUs in einigen Games eine erstaunlich gute Performance gebracht hat. AMD hat dies dann die Idee mit dem großen Cache mit den X3D CPUs wieder aufgegriffen, aber Intel hat sie leider vergessen.

Bei Intel bin ich mir nicht sicher, aber ich denke, es wird wohl wieder ein neuer Unterbau notwendig sein.

Auch wenn die Gerüchte davon sprechen, so wäre ich da nicht zu 100$ sicher, denn Intel dürfte auf DDR6 (wie bei Alder Lake mit der Alternative DDR5) setzen und es davon abhängen, ob DDR6 dann rechtzeitig einsatzbereit sein wird.

Das ist doch schon laaaange bestätigt das Intel wieder ein komplett neuen Sockel und somit ne neue Plattform benötigt wird mit Nova S

Das Intel schon jetzt an einer neuen Plattform für DDR6 arbeitet, sollte nicht überraschen und AMD sollte auch an AM6 arbeiten, wenn sie dies nicht erst in 2 Jahren auf den Markt bringen wollen. Aber bei Nova Lake ist der Memory Controller wieder auf einem eigenen Die und nicht wie bei Panther Lake auf dem Die mit den CPU Kernen untergebracht und dies dürfte daran liegen, dass man da flexibel bleiben möchte. Sollte es bei DDR6,, welches optimalerweise in der zweiten Hälfte 2026 und damit rechtzeitig für Nova Lake-S fertig sein sollte, dann aber massive Probleme und somit Verzögerungen geben, dann sollte es mich nicht wundern, wenn die Nova Lake-S doch nicht im S.1851 kommen und die neue Plattform dann für deren Nachfolger Razor Lake genommen wird. Aber das kann derzeit keiner absehen, selbst Intel nicht.

Derzeit gehe ich davon aus, dass im Oktober oder November ein Refresh von Arrow Lake kommt, vielleicht auch mit 32 e-Kernen im neuen Spitzenmodell, vielleicht nur mit einer stärkeren NPU und vielleicht auch nur mit ein wenig mehr Takt. Ein Jahr später dürfte dann Nova Lake im neuen Sockel mit DDR6 kommen, was ja einen deutlich besseren RAM Durchsatz verspricht, es wird von 12800MT/s als Baseline gesprochen, aber die finale Spezifikation ist noch nicht raus und so viele Kerne wie man sie Nova Lake nachsagt, brauchen auch entsprechend viel RAM Durchsatz um mit Daten gefüttert zu werden. Mehr als 2 RAM Channels halte ich aber für unwahrscheinlich, dies würde auch die Anzahl der Pins des Sockels und damit die Größe des Sockels massiv erhöhen, also machen 52 Kerne bei Dual Channel RAM erst mit DDR6 so wirklich Sinn.

Auf der anderen Seite der Medaille sehe ich nicht, wie Intel mit den Latenzproblemen der neuen Architektur und weiterhin ohne eigene Cache-Lösung in einem überhaupt nur greifbaren Zeitrahmen wieder konkurrenzfähige Gamingleistung bieten will…

Angeblich haben sie bei Nova Lake trotz der Tatsache das der RAM Controller nicht auf dem gleichen Die wie die Kerne sitzt, die Latenz deutlich senken können. Man wird sehen, aber wenn es dann wirklich bis zu 52 Kerne geben wird, dürfte der Fokus weniger auf Gaming- als auf Multithreadperformance liegen.

die Kerne auf drei Dies zu verteilen wird es nicht besser machen.

Das könnte man ja über den Intel Thread Director lösen, indem man dem beibringt das er dem Windows Task Scheduler dazu bringt die Threads der Spiele nur auf den P-Kernen eines Dies laufen zu lassen, ganz ähnlich wie es AMD ja bei den CPUs mit zwei CCDs macht.

Mir fehlt da aktuell als Workstation zusammen mit dem 265k nichts.

Mir fehlt da nur ECC RAM, was ja mit dem W880 Chipsatz geht. Zwar gibt es auch W880 Boards, z.B. das ASUS Pro WS W880-ACE SE, das ASRock RACK W880D4U-2L2Q oder das Gigabyte W880 AI TOP, aber man findet sie noch kaum im Handel. Geizhals listet immerhin schon das ASUS Pro WS W880-ACE SE.

 

[cHio]

Das könnte man ja über den Intel Thread Director lösen, indem man dem beibringt das er dem Windows Task Scheduler dazu bringt die Threads der Spiele nur auf den P-Kernen eines Dies laufen zu lassen, ganz ähnlich wie es AMD ja bei den CPUs mit zwei CCDs macht.

Das löst Intel schon heute ziemlich perfekt dank Hardware Scheduler (Thread Director). Ganz anders als bei AMD wo rein das Betriebssystem entscheidet, wo Software unterstützt. Aus dem Grund hat AMD u.a. beim 9950X3D ja so ein Teils noch arschiges Verhalten bei der Core Zuweisung.
AMD hier als positives Beispiel zu nennen ist quatsch, da ist Intel Lichtjahre voraus und das nicht nur in Gaming Szenarien.

 

[ssj3rd]

Man wird sehen, aber wenn es dann wirklich bis zu 52 Kerne geben wird, dürfte der Fokus weniger auf Gaming- als auf Multithreadperformance liegen.

Denke ich auch, dass Thema Gaming haben sie erstmal aufgegeben.

 

[Stunrise]

In meinen Augen ist das komplett am Markt vorbei entwickelt, ähnlich wie AMD Bulldozer Prozessoren damals. Die üblichen Anwendungen und Spiele für normale PCs und Notebooks brauchen gute Leistung für die ersten <8 Cores und alles darüber kommt in der Praxis nicht zum Einsatz. Arrow Lake bietet durchaus sehr ordentliche Leistung in Multicore Szenarien und trotzdem sind die CPUs waschechte Rohrkrepierer, weil in der Praxis die Performance unzuverlässig und weit unterhalb der Konkurrenz ist.

 

[Holt]

Das löst Intel schon heute ziemlich perfekt dank Hardware Scheduler (Thread Director). Ganz anders als bei AMD wo rein das Betriebssystem entscheidet, wo Software unterstützt.

Keine Ahnung wie es bei AMD aussieht, aber generell ist es so, dass der Task Scheduler von Windows eben von dem entsprechenden Tool des CPU Herstellers (bei Intel eben der Thread Director) Hinweise bekommt, auch welchem Kern sie einen Thread ausführen soll. Der Thread Director greift dafür die Informationen von der CPU zurück, aber als Hardware Scheduler würde ich ihn deswegen nicht bezeichnen, da die Hardware (also die CPU) eben nicht selbst bestimmen kann, wo welcher Software Thread läuft, sondern dies eben nur über den beschriebenen Mechanismus dem Windows Task Scheduler vorschlagen kann.

Das der Windows Task Scheduler nicht mehr alleine entscheidet welchen Thread er auf welchem Kern ausführt, ist übrigens schon recht alt, schon mit der Einführung von Turbo Boost Max 3.0 wurde dies eingeführt, da dieser höchste Takt nur auf bestimmten Kernen erreicht wird und daher eine Software dem Task Scheduler mitteilen musste, welche(r) Kern(e) dies ist/sind.

Spätestens mit den RYZEN 3000 hat auch AMD da sein eigenes Tool gebaut, damit einmal die Singlethreadlasten auf dem am Besten takteten CPU Kern laufen und zum anderen die Threads von Games alle auf dem gleichen CCX laufen, da ja die Latenz zwischen Kernen auf unterschiedlichen CCX sehr viel höher als zwischen den Kernen des gleichen CCX ist, was dann aber Win 10 1903 unterstützt wurde. Keine Ahnung ob es da unterschiedliche Interfaces für den Task Scheduler gibt oder ob AMD erst auf Win 10 1903 warten musste um die Funktion die Threads von Games auf dem gleichen CCX halten zu können, aber am Ende liegt es ja an jedem CPU Hersteller selbst, wie er sein Tool programmiert. Damit auch ob er dazu dynamisch auf die CPU zugreift um Informationen von ihr auszulesen oder ob es dies nur einfach statisch aufgrund des CPU Types macht, aber soweit ich das hier verstehe, hat AMD auch ein Interface zur CPU:

AMD’s Ryzen 3000 processor line-up based on the new Zen2 microarchitecture differs greatly in terms of frequency behaviour compared to past products. The new chips are AMD’s first products to make use of an ACPI feature called CPPC2 (Collaborative Power and Performance Control 2) which is an API interface between the chip’s firmware (Essentially the UEFI BIOS and AGESA) and an operating system such as Windows. The interface allows for the hardware to better communicate its frequency and power management characteristics and configurations to the OS, such that the OS’s software DVFS and scheduler are able to more optimally operate within the capabilities of the hardware.

Es scheint auch noch der Windows Energiesparplan eine Rolle zu spielen, wenn ich hier auf Seite 12 lese was AMD für die EPYC 8004 und Windows Server zu dem Thema schreibt.

Es ist aber eben seit Win 10 1903 definitiv nicht mehr so, dass bei AMD alleine das Betriebssystem entscheidet wo welcher Software Thread läuft! Wenn das doch mal der Fall ist, dann hat man vermutlich vergessen etwas zu installieren oder die installierte AMD Software hat einen Bug.

Die üblichen Anwendungen und Spiele für normale PCs und Notebooks brauchen gute Leistung für die ersten <8 Cores und alles darüber kommt in der Praxis nicht zum Einsatz.

Erstens bricht doch nichts dagegen das bei der CPU auch die Lasten die nur 8 P-Kerne voll auslasten, eine sehr gute Performance haben werden und zweitens ist die Praxis bei jedem anderes, in meiner Praxis kann ich auch 52 Kerne gut auslasten.

weil in der Praxis die Performance unzuverlässig und weit unterhalb der Konkurrenz ist.

Das ist doch Blödsinn, inzwischen ist auch die Gaming Performance von Arrow Lake nicht mehr so schlecht wie in den ersten Reviews und was meinst du damit die Leistung wäre unzuverlässig?

Beitrag automatisch zusammengeführt: 17.06.2025

Aber irgendwie schon komisch, wie schnell die AMD Fans ihre Meinung ändern können. Als die Zen erschienen sind, konnten sie bei der Gamingperformance nicht mithalten, lagen aber wegen ihrer 8 Kerne bei der Multithreadperformance vorne und wurden dafür bejubelt. Nun hat AMD mit den X3D CPUs die die Krone der Gamingperformance haben und auf einmal ist die Multithreadperformance nicht mehr wichtig, die Kerne werde ja angeblich in der Praxis gar nicht genutzt. Dabei wird nicht über den eigenen Bauchnabel hinweggeschaut, sonst würde man ja erkennen, dass in der Praxis nicht jeder die gleichen Anforderungen hat!

 

[cHio]

Richtig: Der Thread Director entscheidet nicht selbst, wo ein Thread läuft. Stattdessen liefert er Laufzeit-Telemetrie (z. B. Instruktionsmix, Last, Energiebedarf) direkt aus der Hardware an das Betriebssystem.
Diese Daten fließen dann in die Entscheidung des Windows Task Schedulers ein, der die endgültige Zuweisung der Threads vornimmt.
Der Thread Director misst live, wie ein Thread läuft, heißt: Ist es ein rechenlastiger Thread? Nutzt er viele Branches? Läuft er speichergebunden? Ist niedrige Latenz oder hohe Energieeffizienz besser? Diese Infos gehen zyklusgenau direkt an den Windows Scheduler (ab Windows 11). Der Scheduler kann viel bessere Entscheidungen treffen als nur mit „CPU ist ausgelastet“-Daten wie es z.B. bei AMD der Fall ist. Das verbessert insbesondere Performance bei gemischten Workloads (z. B. Multitasking, Hintergrundtasks + Gaming).
Ohne Thread Director ist es für das OS zudem schwer zu wissen, welche Threads zu welchem Kern passen, grade bei Hybrid Architekturen (X3D ist auch eine Art Hybrid Architektur). Hätte AMD sowas ähnliches in Hardware, wäre das X3D CCD Zuweisungsproblem deutlich einfacher zu handhaben. So muss AMD per Software zu neuen Spielen immer erst manuell den Support herstellen.

Ich habe schon etliche Anwendungen entwickelt wo das Thema "Runtime-System" entscheidend war und Intel ist da zur jetzigen Zeit einfach eine ganz andere Liga.

 

[Holt]

Ohne Thread Director ist es für das OS zudem schwer zu wissen, welche Threads zu welchem Kern passen, grade bei Hybrid Architekturen (X3D ist auch eine Art Hybrid Architektur). Hätte AMD sowas ähnliches in Hardware, wäre das X3D CCD Zuweisungsproblem deutlich einfacher zu handhaben. So muss AMD per Software zu neuen Spielen immer erst manuell den Support herstellen.

Die X3D sind ja nur dann eine Hybrid Architektur, wenn es um die Modelle mit zwei CCDs geht, weil da ja nur einer den zusätzlichen 3D Cache hat. Aber wenn AMD sowas nicht in Hardware hat, dann ist dies alleine AMDs Schuld, es hindert sie ja keiner daran dies zu implementieren. Nicht einmal wenn Intel da Patente drauf hat, würde es AMD davon abhalten können, da beide ein Patentaustauschabkommen haben. welches alles umfasst was x86 CPUs betrifft. AMD kann also alles kopieren, was Intel in seine CPUs einbaut (und umgekehrt), ohne dass Patente dem im Wege stehen könnten, wenn sie es nicht tun, dann weil sie es nicht wollen.

 

[AyC]

Arrow Lake bietet durchaus sehr ordentliche Leistung in Multicore Szenarien und trotzdem sind die CPUs waschechte Rohrkrepierer, weil in der Praxis die Performance unzuverlässig und weit unterhalb der Konkurrenz ist.

Mein 300€ teurer 265k mit 192GB RAM läuft in Games und Anwendungen min. mal auf 9900x Niveau, welcher zu fast jedem Zeitpunkt 70-100€ teurer war... Dazu stimmt auch die Effizienz, im Idle deutlich besser und in Games und Anwendungen muss sich die CPU auch nicht verstecken. Und da ist noch nicht einmal eingerechnet, dass der 9900x niemals 5600Mhz bei 192GB schafft.

Aber wenn du von Konkurrenz sprichst, eigentlich müsste man den 20 Kerner gegen den 9700x mit 8 Kernen vergleichen. Die beiden CPUs kosten das Gleiche und jetzt sagst du, dass die Performance unzuverlässig (was bedeutet das?) und unterhalb vom 9700x ist?

 

[denni]

Hmm, ich hatte in der letzten Zeit nicht so unbedingt den Eindruck, daß die Schnittmenge aus Realität und Intels Marktanalyse besonders groß gewesen wäre.

Kann sein das es aktuell eine schlechte Phase ist, und gerade AMD hatte diese bereits mehr als einmal , und ist aktuell vorne. Ich sehe nicht warum Intel sowas nicht gelingen sollte. Nach dem P4 hat Intel AMD mehr als ein Jahrzehnt easy in der Hand gehabt. Ich sehe das nicht so eng, denn wenn Intel zurück kommen sollte ist es für alle gut, gerade für diejenigen die möglicherweise weiterhin einigermaßen bezahlbare AMD CPUs haben wollen…

 

[Holt]

gerade AMD hatte diese bereits mehr als einmal , und ist aktuell vorne.

Vorne ist AMD was die Gamingperformance angeht, bei Server CPU was die maximale Performance pro CPU angeht, aber dafür gibt es auch nur maximal 2 CPU pro Server, bei Intel sind es 8. Was den gesamten Markt angeht, so hat Intel insgesamt immer noch um die 75% Marktanteil bei x86 CPUs, hier ist Intel also immer noch weit vorne.

 

[denni]

Hatte vergessen im Consumer Bereich hinzuzufügen.

 

[Shihatsu]

Das Intel im Serverbereich vorne ist hat nur wenig mit der Qualität oder Leistung zu tun, sondern mit langfristigen Verträgen, Lobbyarbeit ohne Ende und dem Unvermögen von AMD (in der Vergangenheit, mitlerweile ist das besser) etwas gegen das Intel embedded Programm zu haben. Das Embedded Programm sorgt dafür das bestimmte Chips sehr lange lieferbar sind, obwohl sie für den Consumermarkt schon lange keinen Sinn mehr machen. Das kann AMD mitlerweile auch bei den EPYCs, aber das wird noch ein langer K(r)ampf dagegen anzustinken.

 

[Holt]

Hatte vergessen im Consumer Bereich hinzuzufügen.

Auch im Consumerbereich liegt Intels Marktanteil weit vor dem von AMD. Im Serversegment hat AMD sogar einen etwas größeren Marktanteil als insgesamt, aber der Unterschied ist auch nur wenige Prozentpunkte zwischen den verschiedenen Marktsegmenten. Nur in Segmenten an die die wenigstens hier im Forum denken, wie Embedded, Industrial und Military, hat Intel die Nase weit vorne, aber da sind die Zyklen eben auch sehr lang und AMD hatte lange nichts nennenswertes in den Segmenten anzubieten und ich weiß nicht einmal, was sie da heute anbieten.

 

[cHio]

Intel hat noch ein entscheidenden Vorteil. Es gibt eine massive Anzahl an Unternehmen die veraltete Anwendungen und Programmbibliotheken nutzen, die deutlich besser auf Intel performen. Selbst wenn die Systeme schon lange in der Cloud sind oder auf anderen modernen Plattformen. Teilweise wird sogar der ganze alte Scheiss in ein Container gepackt aber an die Architektur der Software traut sich selten einer ran. Die werden dann oft maximal rudimentär gewartet & weiterentwickelt um im besten Fall halbwegs internen Security & fachlichen Anforderungen gerecht zu werden.
Solange sich an dieser Mentalität nix ändert wird AMD es schwer haben sich durchzusetzen. Noch dazu kommt dieses, "Wir hatten nun 20 Jahre Intel Plattformen, nur um x-tausend € zu sparen wechseln wir nicht auf den unbekannten Konkurrenten AMD."
Da hat Intel einfach gute Lobbyarbeit gemacht die letzten Jahrzehnte. Mit der Performance der Hardware hat das heutzutage eher weniger zu tun.

 

[Holt]

die veraltete Anwendungen und Programmbibliotheken nutzen, die deutlich besser auf Intel performen.

Weil Intels Compiler eben die Software extrem gut optimiert und AMD dem nie etwas entgegen gesetzt hat, was ja nur AMDs und nicht Intels Schuld ist. Dieser Code läuft dann optimal auf Intels CPUs und das ist auch der Grund warum Intels CPUs immer noch bei Familie 6 ausgeben, denn nur bis dahin geht die Optimierung des Compilers, würde Intel da jemals auf 7 gehen, würde dieser alte Code langsamer laufen, weil er keinen Codepath hat, der für Intels 7. Familie optimiert wurde.

 

[cHio]

Intel hat aber aktiv dafür gesorgt, dass alternative Codepfade nicht genutzt wurden. Also ist es nicht nur eine „neutrale“ Compilerentscheidung. Heute ist das besser geworden, auch durch Open Source Compiler wie LLVM/Clang und GCC, die neutraler optimieren.

 

[Holt]

Intel hat aber aktiv dafür gesorgt, dass alternative Codepfade nicht genutzt wurden. Also ist es nicht nur eine „neutrale“ Compilerentscheidung.

Welchen Grund sollte Intel haben Aufwand zu treiben, damit sein Compiler den Code für CPUs anderer Hersteller optimiert? Erstens ist es deren Sache selbst einen Compiler zu entwickeln der den Code für ihre CPUs optimiert denn zweitens kennen nur diese, wie dies zu geschehen hat. Soll Intel etwa jemanden beschäftigen und bezahlen, damit er genau studiert wie die Cachegrößen und Befehlsfolgen für deren CPUs zu optimieren ist? Das kann niemand im Ernst erwarten oder gar verlangen!

Heute ist das besser geworden, auch durch Open Source Compiler wie LLVM/Clang und GCC, die neutraler optimieren.

Keine Ahnung wie es heute aussieht, aber vor einigen Jahren noch, hat mir jemand der damit direkt zu tun hat, ganz klar gesagt das die alle nicht an den Intel Compiler ran kommen, wenn man den Code dann auf einer Intel CPU ausführt. Deshalb wird der Intel Compiler so oft genutzt, obwohl er nicht umsonst zu haben ist, aber wenn die Software mit dem compiliert mal eben 10 oder 20% schneller läuft, lohnt sich das schon.

Aber wie gesagt: Niemand hat AMD daran gehindert selbst einen Compiler zu bringen, der den Code auf ihren CPUs besser optimiert. Sie haben aber lange einen wenig bekannten Open Source Compiler unterstützt und nun gibt es mit dem AOCC wohl einen eigenen AMD Compiler.

 

[cHio]

Holt ganz ehrlich, deine Beiträge sind, extrem freundlich ausgedrückt, anstrengend.

Intel hat nicht einfach nur "nicht für AMD optimiert", sondern in älteren ICC-Versionen aktiv vermieden, schnelleren Code auf AMD auszuführen – selbst wenn die CPU die benötigten Features unterstützt hat. Intel nutzte dabei CPU-Vendor-Checks, nicht Feature-Checks. Das ist kein technischer Zufall, sondern ein bewusstes Design. Das wurde in mehreren Kartellverfahren (u. a. FTC 2009) als wettbewerbswidrig bewertet.
Intel hat aktiv behindert, dass Software auf AMD effizient lief, indem es versteckte Codepfade nur Intel-CPUs zugänglich machte. Das ist mehr als einfach „nicht optimieren“, es ist eine technische Blockade.

AMD hatte nicht die gleichen Marktchancen, weil weniger Einfluss auf Compiler-Ökosysteme, geringere finanzielle Ressourcen, weniger Einfluss auf Softwareanbieter, Benchmarks usw. Die Aussage „Niemand hat AMD gehindert…“ ist also rein formal richtig, ignoriert aber das Machtgefälle. Intel war nicht nur Technologieführer, sondern vor allem Machtakteur. Das Unternehmen hat seine Marktdominanz mit allen Mitteln verteidigt, von legalem Business Development bis zu nachweislich wettbewerbswidrigem Verhalten. Das erklärt, warum AMD trotz teils überlegener Technik oft „verliert“. Nicht wegen schlechter CPUs, sondern wegen eines strukturellen Nachteils, der über Jahrzehnte aufgebaut wurde.

Beim letzten Absatz disqualifiziert du dich komplett selbst. Du kennst den aktuellen Stand nicht, äußert dich aber abschwächend („früher war das halt so“) über ein sehr relevantes Thema. In der Sache wirkt dein Beitrag einseitig, apologetisch und so, als würdest du den Kontext bewusst klein reden.

Wenn man wie ich jahrelang knietief in der Materie drin ist, die ganze Evolution miterlebt hat, merkt man auch sofort wenn jemand Praxis Know-How besitzt und wirklich mitreden kann oder eben nicht.
Das wars von mir zu dem Thema. Tschö.

 

[Holt]

Holt ganz ehrlich, deine Beiträge sind, extrem freundlich ausgedrückt, anstrengend.

Erstens musst du sie nicht zweitens ist es nicht meine Schuld, wenn du es anstrengend findest zu versuchen mich zu widerlegen.

Beim letzten Absatz disqualifiziert du dich komplett selbst. Du kennst den aktuellen Stand nicht, äußert dich aber abschwächend („früher war das halt so“) über ein sehr relevantes Thema.

Weil die Leute von denen ich das haben, dafür bezahlt werden Software zu entwickeln und nicht ständig nur die jeweils neusten Versionen unterschiedlicher Compiler zu vergleichen. Dies darfst du aber gerne selbst machen, aber in den meisten Firmen macht man dies eben nicht immer mal wieder nach Lust und Laune. Selbst bin ich aus dem Thema nämlich schon eine Weile raus und programmiere heute kaum noch in C++ und wenn, dass ist das nicht so performancekritisch, als dass ich mir um die Optimierungen Gedanken mache.

Wenn man wie ich jahrelang knietief in der Materie drin ist, die ganze Evolution miterlebt hat

Dann vergleiche doch bitte selbst wie gut welcher Compiler für welche Architektur optimiert. Aber ich habe massive Zweifel an der Aussage, dass du da tief drin steckst.

 

[IronAge]

Aber ich habe massive Zweifel an der Aussage, dass du da tief drin steckst.

Hörensagen vs. Software-Entwickler, möchte mal wissen wie du das von der Hörensagen Warte aus bezweifeln können willst.

 

[reppetstoH]

Ich hab hier letzte Woche spaßeshalber eine Kiste aus übrig gebliebenen teilen zusammengeschraubt.

Athlon 3000G (2 Kerne - irgendwann mal zum BIOS updaten gekauft)
GTX 1050 Ti
Asus B550 Board
NVME SSD
16 GB RAM auf 3666MHz übertaktet mit scharfen Timings.

Ganz ehrlich... Kiste ist absolut überraschend schnell im alltäglichen Office Kram. Und auch Dinge wie Portal 2 laufen bei konstant 144Hz über den gsync Schirm.

Erdet einen irgendwie das zu erleben.

 

[cHio]

Hörensagen vs. Software-Entwickler, möchte mal wissen wie du das von der Hörensagen Warte aus bezweifeln können willst.

Er kann ja nicht Wissen was ich beruflich mache oder was meine Qualifikation ist. Daher nehme ich das nicht so ernst im Internet.
Es ist schon herzallerliebst, wenn man sofort sieht, wenn jemand mit google Wissen und Quelle "Kuseng" einem die Welt erklären möchte. Und dann auch noch mit asbach uralt Hobby Programmierkenntnissen, wo Performance nie ein Thema war, hier den Lehrmeister macht. Aber hey, manchmal lese ich seine bibelartigen Beiträge gerne.

 

[pwnbert]

Hörensagen vs. Software-Entwickler, möchte mal wissen wie du das von der Hörensagen Warte aus bezweifeln können willst.

Als Human-LLM schwurbelt es sich eben besonders gut...

Aber das ist ja nix neues.

 

[reppetstoH]

Welchen Grund sollte Intel haben Aufwand zu treiben, damit sein Compiler den Code für CPUs anderer Hersteller optimiert? [...] Soll Intel etwa jemanden beschäftigen und bezahlen, damit er genau studiert wie die Cachegrößen und Befehlsfolgen für deren CPUs zu optimieren ist?

So war es nur eben nicht. Intel hat Aufwand betrieben um seine Compiler und Libs für die Wettbewerber zu pessimieren. Also aktiv seine Marktmacht dazu benutzt um AMD keine gleichen Wettberwerbsbedingungen zu erlauben. Mir ist aber klar, dass du das alles weisst und aus Überzeugungen heraus anders wertest.

 

[Holt]

Er kann ja nicht Wissen was ich beruflich mache oder was meine Qualifikation ist.

Ebensowenig weißt du, was ich studiert habe und beruflich mache. Ich habe nicht nur Hobby Programmierkenntnisse und Performance hat da bis vor einigen Jahren immer eine Rolle gespielt, nur schreibe ich nicht die dafür relevanten Codes, sondern den wo diese dann integriert werden und daher habe ich durchaus engen Kontakt mit den Leuten die diese schreiben. Aber egal, ich muss jemandem der nicht den Unterschied schon seriellen und parallelen Schnittstellen kennt, nichts beweisen. Aber auf meine IL!

 

[Shihatsu]

Nimm das, cHio!

Willkommen auf der Liste der coolen Leute, bleib bei uns, hier ists kuschelig

 

[DerGoldeneMesia]

Die Tdp wird so hoch sein weil sie den Takt hochzüchten bei gleichzeitig sovielen Einheiten, dafür hatte Intel "Idle" weniger Verbrauch.

Für Gamer war Amd daher sinnvoller.

 

[Holt]

Die vielen Kerne erfordern natürlich schon eine gewisse TDP, damit sie auch bei Volllast einen einigermaßen hohen Takt erreichen können. Hier zur Erinnerung noch mal die Leistung (Punkte bei CB MT) bei verschiedenen Power Limits für den 285K und seine Konkurrenten, welches ich schon mal gepostet hatte:

Wie man sieht hat der 285K bei so 75W die beste Effizienz, wenn man nun zwei von den Dies mit den CPU Kernen in eine CPU packen würde, so müsste man der eben 150W gönnen um an diesen Sweet spot zu kommt und die großen Nova Lake werden ja offenbar zwei CPU mit je 8+16 Kernen bekommen. Das werden natürlich nicht die gleichen Dies wie bei Arrow Lake, die CPU Architekturen werden neuer sein und die Fertigung ebenso, es ist von Intel 18A-P auszugehen, aber dies ändert nicht daran, dass man halt grundsätzlich mehr Leistungsaufnahme bei mehr Kernen erlauben muss, damit diese wenigstens an ihren Sweet spot der Effizienz kommen können.

Die Mainboardhersteller werden dann aber sicher wieder Profile anbieten die Power Limits enthalten die weit über Intels offizieller TDP Angabe liegen und für die CPU sind nur die Power Limits des BIOS relevant, nicht welche TDP im Datenblatt steht.

 

[jdl]

Intel hat nicht einfach nur "nicht für AMD optimiert", sondern in älteren ICC-Versionen aktiv vermieden, schnelleren Code auf AMD auszuführen – selbst wenn die CPU die benötigten Features unterstützt hat. Intel nutzte dabei CPU-Vendor-Checks, nicht Feature-Checks. Das ist kein technischer Zufall, sondern ein bewusstes Design. Das wurde in mehreren Kartellverfahren (u. a. FTC 2009) als wettbewerbswidrig bewertet.
Intel hat aktiv behindert, dass Software auf AMD effizient lief, indem es versteckte Codepfade nur Intel-CPUs zugänglich machte. Das ist mehr als einfach „nicht optimieren“, es ist eine technische Blockade.

Ich habe jahrelang auf AMD Opterons selbst übersetzte HPC-Software laufen lassen. Dazu gab es eine Auswahl an Compiler, GCC, Intel Compiler Suite, PGI, Pathscale, alten AMD Compiler (Open64 vollkommen unbrauchbar) …

Für die optimale Performance auf diesen alten 64Bit AMDs reichte es aus Standard Optionen zu benutzen, und die optimale Performance wurde je nach Code mit GCC oder Intels Compiler Suite erreicht. Was bei den Intel Compiler nicht funktionierte war das automatische Threadpinning der OpenMP Library des Intel Compilers. Das musste man mit zwei, drei Programmaufrufen von Hand machen (der Code lässt sich dann von allen Compiler übersetzen und läuft auf allen Plattformen). Danach lief die Software analog zu Code den man mit dem GCC übersetzt hat. In der Tat unterstützte der alte Intel Compiler (der neue basiert auf Clang und hat das Feature nicht mehr) die Möglichkeit optimierten Code für verschiedene CPUs einzubauen. Welcher Code das war, war eine Entscheidung des Entwicklers und nicht des Intel Compilers, das musste man von Hand mit Compilerflags aktivieren.

Wenn wir über optimierten Code reden, müssen wir über die verschiedenen ABIs reden. Es ist ein wesentlicher Unterschied, ob es sich um eine 32Bit ABI oder eine 64Bit ABI handelt. Auf den 32Bit CPUs gibt es eine sehr große Variation an CPU-Features, so dass es schwierig ist Programmcode für 32Bit Systeme zu optimieren. Und leider ist das so, dass AMD und Intel nicht immer die gleichen Befehlssatzerweiterungen unterstützt haben. Daher wurde für 32Bit Systeme üblicherweise als Standardcodepfad irgend eine alte CPU gewählt, und nur dann wenn die Laufzeitumgebung einen neuen Intel Prozessor feststellt wird, wird auch schnellerer Code ausgeführt.

Bei 64Bit CPUs ist das hingegen deutlich einfacher. Alle Intel CPUs mit 64Bit unterstützen SSE4.1. Wenn man nur eine Generation (Core2) weglässt ist es sogar SSE4.2. AMD64 CPUs hingegen gab es bereits als es nur SSE3 gab. Daher läuft Code Code aus einem Intel 64Bit Compiler nur ab einer bestimmten AMD Generation. Was das Thema FMA3, FMA4, AMX, AVX, AVX2 und AVX512 betrifft. FMA4 ist tot, das gab es nur kurz auf AMD. FMA3 läuft ab Haswell auf Intel und bei AMD schon früher. AVX2 ist ebenfalls ab Haswell verfügbar. Eigene Test zeigen mir aber, dass der Autovektorisierer keine gute Arbeit abliefert. D.h. man schreibt für den ganzen AVX Kram am besten den Code von Hand. Aktuell ist das so, dass AMD FMA3, AVX, AVX2 und AVX512 unterstützt. Das Problem ist wieder einmal, dass Intel CPUs entweder FMA3, AVX, AVX2 (alle aktuellen Desktop, Mobile und kleinen Server bis maximal Xeon 6 E) unterstützten oder FMA3, AVX, AVX2, AMX und AVX512 (die großen Xeon mit P Kernen). D.h. optimiert man Code für aktuelle Xeon P läuft dieser Code nicht mehr auf AMD, weil die kein AMX haben.

Intels Tricks spielen sich in den letzten Jahren eher in den handoptimierten Laufzeitbibliotheken (MKL o.ä.) ab. Da kann man aber auf AMD Systemen mit Umgebungsvariablen eingreifen, so dass trotzdem die schnellere Version geladen wird.

Die aktuelle Intel Compiler Suite basiert nun auf der Clang Compiler Suite, und erlaubt keine Codeweichen mehr. D.h. man muss die Funktionalität wie mit jedem anderem Compiler in eine Shared Library auslagern, von der man die passende Version erst zur Laufzeit nachlädt. D.h. genau das was man mit einem GCC, PGI, … schon immer tun musste.

Apropos nVidia hat die Portland Group gekauft, und bietet die Compiler Suite nur noch für Linux (Intel64 und Aarch64) an. Auch dieser Compiler wurde auf Clang umgestellt.

AMD hatte nicht die gleichen Marktchancen, weil weniger Einfluss auf Compiler-Ökosysteme, geringere finanzielle Ressourcen, weniger Einfluss auf Softwareanbieter, Benchmarks usw.

AMDs Problem war viele Jahre, dass sie absoluten Schrott an Software abgeliefert haben. Der Open64 Compiler und die ACML HPC Library waren ein ganz übler Scherz.