Volker schrieb:
Speichercontroller im I/O-Tile?
Die neue Folie spricht davon, dass nun die I/O-Tiles auch den Speichercontroller enthalten sollen, was im kompletten Widerspruch zu dem steht, was Intel bei Granite Rapids noch gesagt hat. Dort hatte Intel die Speichercontroller explizit in den CPU-Tiles gelassen, da diese Umsetzung mehr Leistung bei gleichzeitig besseren Latenzen gegenüber der Auslagerung dieser Einheiten in einen anderen Tile liefert.
Ich finde diese Änderung irgendwie extrem, da sie doch schon ziemlichen Einfluß auf die Performance hat.
Man erinnere sich an dieser Stelle an Arrow Lake, was meiner Meinung nach verhungert, da zu berechnete Datenströme ja den kompletten
Uncore-Bereich des SoC-Tile durchlaufen müssen, um bis zum Speicher-Controller (und wieder den selben Weg zurück) zu gelangen – Resultat war erhebliche Mehr-Latenzen und kaum zu verortende Leistungseinbrüche.
Den einzigen Grund, weswegen die Speicher-Controller jetzt in den I/O-Die gewandert sind, kann man sich eigentlich nur dadurch erklären, daß die
Yield bei 18A offensichtlich noch immer nicht ausreicht, um die ansonsten
größeren CPU-Tiles (inkl. Speicher-Controller) bei entsprechend hoher Ausbeute (mit ausreichend hoher benötigter Kern-Anzahl; +48 Core-count) bei ausreichender Stückzahl zu fertigen.
Also versucht Intel die Die-Größe der Compute-Dies zu reduzieren und verfrachtet die Speicher-Controller auf den I/O-Die, um die Größe der Compute-Dies zu klein wie möglich zu halten (und damit die Ausbeute höher). Weil von den I/O-Dies braucht Intel ohnehin nur ein Viertel der Compute-Dies, welche auch auf einem anderen älteren Prozeß gefertigt werden können (einer, mit besserer Yield).
Ich frage mich bis heute, wie man ernsthaft annehmen kann, mit 18A sei alles in Ordnung …
Es gibt meiner Meinung nach bis jetzt
keinerlei Indizien für hohe Yields bei 18A – Da genaue Gegenteil ist der Fall, jede Menge Indikatoren, daß Intel den Prozeß noch immer nicht vernünftig zum Laufen hat bekommen.
