CCIBS schrieb:
Ich bin ja gespannt, wie sich dann die P und E Core in der Xeonfamilie entwickeln.
Sierra Forrest hört sich ja im Grunde schon wie das Konzept von Intel Xeon Phi (Larrabee) an.
[...]
Ich verstehe wie man hier Analogien zum Xeon Phi sehen kann. Vermutlich ist es am Ende aber doch ein nochmals anderer Weg.
Bspw. setzte man beim letzten Xeon Phi (KNL/M) zwar auch auf viele "E" cores in einer CPU. Allerdings flanschte man an diese zwei sehr große VPUs (AVX512) und schnellen Cache (MCDRAM) um die gewünschte Leistung zu erreichen. Um dann noch im Power Budget zu bleiben musste die Taktfrequenz pro Core stark reduziert werden. Man könnte sogar soweit gehen und sagen die "E" cores waren nur da um die VPUs zu füttern. Mit diesem Ansatz versprach mit sich eine hohe Leistung und Effizienz für hoch parallelisierbare (Vektorisierung und Multi-Threading) Anwendung.
Dies sollte eine Konkurrenz zu den sich immer weiter im HPC Bereich verbreitenden GPUs werden.
Bei Sierra Forest sehe ich einen anderen Gedanken: Viele Anwendungen, v.a. web-basierte, können schlicht nicht stark von AVX512, geschweige den von AMX, profitieren. Bei diesen Anwendungen ist ein "E" core ohne diese Features und vsl. kleinerem Cache nicht gravierend langsamer als ein "P" core aber weitaus effizienter.
Um eine bessere Kompatibilität zu erreichen unterstützen zukünftige "E" cores womöglich AVX512 Befehlssätze. Ich bezweifel aber stark das diese tatsächlich 512bit große Vektoreinheiten besitzen werden.
Dies ist auch ein anderer Ansatz von Parallelisierung: Beim Xeon Phi wollte man ein einzelnes parallelisierbares Problem möglichst Effizienz lösen. Hier geht es nun um die parallele Bearbeitung von möglichst vielen unabhängigen Problemen.
Der Markt ist schlicht hinreichend groß um eine eigene Lösung hierfür zu rechtfertigen. Durch die gemeinsame Platform und I/O können die Kosten stark reduziert werden.
CDLABSRadonP... schrieb:
Das stimmt...
...es ist aber nur eine weitere Gemeinsamkeit, während ansonsten wirklich gar nichts an Naples und Rome erinnert.
Von Seiten des Nutzers/Softwareentwickler erinnert Sapphire Rapids sehr stark an Naples. Ähnlich wie bei Naples sind auch hier die Cores in "Gruppen" mit eigenen Caches (inklusive HBM), Memory Controller (je 2 Kanäle), PCIe etc. unterteilt. Bei über die gesamte CPU parallelisierten Anwendungen muss ich als Nutzer nun darauf achten nach möglich nur auf Daten zuzugreifen die von meinem lokalen Memory Controller geliefert werden können. Ansonsten gehen die Daten den Umweg über eine andere "Gruppe".
Man könnte nun zwar argumentieren, dass auch beim bisherigen Mesh die Lokalität einen starken Einfluss hatte. Ich vermute aber sehr stark das der Einfluss nun bei den Tiles im Vergleich zum Mesh stärker sein wird.
Auch diese CPUs werden entsprechend so konfigurierbar sein das sie vom Betriebssystem als 4 NUMA Domains erkannt werden. Dies ist bei der Optimierung, sowohl der User Anwendung als auch beim Prozess Scheduling durch das Betriebssystem sehr hilfreich. Auch beim Mesh gab es bereits derartige Optionen zur Optimierung für bestimme Anwendungen.
Ich spreche hier absichtlich von "Gruppen", da dies bei jeder Implementierung schlicht anders genannt wird.
Dieses Konzept ist übrigens auch nicht auf x86 beschränkt. Bei ARM CPUs sind ähnliche Optimierungen nötig. Siehe bspw. die Unterteilung in 4 CMGs beim Fujitsu A64FX.
