News Intel-Xeon-Architektur: Granite Rapids und Sierra Forest mit 144 Kernen detailliert

foofoobar schrieb:
Und warum handhabt Windows das anders?

Zur Marktsegmentierung. Die wollen fuer Windows Server einfach mehr verlangen als fuer Windows Home.

Linux hat ein anderes Geschaeftsmodell, da gibt es einen Kernel, der eben alles unterstuetzen soll. Und wenn dann ein Handy-SoC-Hersteller kommt und seine Privatversion macht, wird er schief angeschaut.
 
latiose88 schrieb:
Ja stimmt es gibt auch windows server Betriebssystem zu holen. Funktioniert soweit ich weiß aber anderst als die normalen windows Betriebssysteme. Und wenn dann ein privatuser sowas nutzt der muss sich dann schon gut auskennen. Ansonsten steht dieser ratlos vor dem Bildschirm und weiß nicht was er am besten machen soll mit dem ganzen.
Ich selbst hatte noch nie nen Windows server betriebsystem gehabt. Darum kann ich leider dazu nix schreiben oder was dazu sagen.

Also wenn ich mir Windows Server auf der Arbeit im RZ so anschaue, das wäre für mich keine schöne Basis für ein Desktop Betriebssystem.

Windows 2000 Server war früher mal bei einem Freund von mir für Recording ganz beliebt, ist aber schon so lange her, dass ich vergessen habe warum es bei ihm dann unbedingt Windows 2000 Server sein musste. Damals war es jedenfalls noch nicht so fett und vielleicht waren einige Dinge sogar wirklich effizienter, weil ein paar Desktop Related services möglicherweise gar nicht aktiv waren.

Aber auch bei den Services kann man mit tools Hand anlegen und verschiedene Profile bereitstellen, die bei entsprechendem Bedarf das eine oder andere rasch aktivieren oder deaktivieren könnte.
Meine Meinung dazu: nur wenn man es wirklich braucht, ansonsten zu viel Vodoo und das potential sein Setup zu über-verkomplizieren und zu verbuggen, wenn man nicht genau weiß was man tut und alles gründlich getestet hat (was ne Menge Zeit in Anspruch nimmt und wenn de Pech hast, findste nicht gleich alles sondern irgendwann später im "tiefen Tal der Tränen" wenn was nicht funktioniert und Du weißt nicht warum, obs an Dienem optimierten / vergurkten setup liegt oder nicht).
Ergänzung ()

xexex schrieb:
Dafür gab es damals wie heute die Workstation Plattformen, dafür gibt es dann auch Boards und Treiber für die Windows Desktops.
https://www.computerbase.de/2022-12...-workstations-und-hedt-bieten-6-bis-56-kerne/

Ahaaa, dankeschön für die Info, sehr nett von Dir, das war mir durchgegangen.
Nun ja, im Moment bin ich auch noch nicht auf der Suche (nach neuer Hardware).
Ich reite aktuell mein System mit Win10 noch so lange ab, wie nur geht, weils noch geht.
 
Ja genau so sehe ich das auch. Ich habe ja das Problem das ich nur Programme habe die bis zu einer gewissen Kern Zahl damit skalieren. Finde ja sogar die workstation besser auch wenn diese nur wenige Kerner hoch takten. Aber selbst die verliert gegen einen Pendant von threadripper.
Weil dieser ja mit 32 Kernen 4,6 GHz taktet gegen ne Intel mit zwar 36 kernen wo nur 12 kener 4,8 GHz takten und der Rest so bei 3,0 bis 3,2 GHz maximal. Ist halt noch immer weniger Leistung.
Finde ich echt schade. Aber gut da kann man eben nix machen.

Bei den Servern wird es gegen die Server von AMD auch genauso enden wie ich das halt so sehe.
 
Nagilum99 schrieb:
Die E-Kerne sind bei klassischer Virtualisierung im SMB-Bereich Gammel. Da kann ich auch mit 'alten' P-Kernen weiter arbeiten. Nach wie vor skaliert hier vieles nicht und ich kann nicht unendlich VMs auf das Ding werfen um das Problem zu lösen.

Klar, wenn Du Aufgaben hast, die nicht gut mit der Core-Anzahl skalieren, dann greifst Du natuerlich zu einem P-Core-Xeon. Aber wenn Du Aufgaben hast, die gut skalieren, dann bietet ein E-Core-Xeon wohl mehr Leistung. Fuer beide Szenarien bietet Dir Intel etwas an, und AMD auch.
 
latiose88 schrieb:
Ja weil ich kein aktuellen Server jemals besessen hatte.Kann nur was war schreiben.Ganz vergessen gehabt wie sehr sich das alles zum negativen geändert hatte
hat es nicht
 
  • Gefällt mir
Reaktionen: Nagilum99
Intel setzt auf seine bekannte Stärke: Breites Angebot an verschiedenen CPUs und neu, deren Konfiguration. Da sind sie schon länger besser aufgestellt als AMD.

Die Frage ist halt, welche Performance da rauskommt. Schauen wir mal, es wird bestimmt spanned.
 
Achja, der Folienweltmeister mit seiner warte ich muss kurz nachschauen: "On-Time Execution across the roadmap". Ahja.

Mit dem "across" meinen die das halt wortwörtlich. Weil von "On-Time" bei den Servern kann bei Intel schon seit Jahren nicht mehr die Rede sein und für die Zukunft sieht es kaum besser aus - es wird immer fleißig geschoben und herumlaviert. Sehe ich schon an den groben Datierungen unten in der Zeitleiste. Reicht ja wenn ein ES Die zum Partner am 31.12.2025 kommt und schon ist das "On-Time Execution" in 2025. Geplant war die CPU dann aber eigentlich für 2023 :D
 
Gibt es eigentlich Aussagen wie L1d der P-Cores beschaffen sein wird? Bei x86 wäre es schon merkwürdig, wenn L1i mit 64kB größer ist als die 48kB L1d, wie Raptor Cove aktuell konfiguriert ist.

@Volker Vielleicht habe ich es überlesen, aber bei den P-Cores steht eine Entwicklung nicht im Artikel. Die FPU Pipeline wird wohl deutlich verkürzt. Derzeit 4..5 Takte auf geplant 3 Takte bzw. Stufen. Schreibt zumindest TomsHardware und Anandtech (https://www.tomshardware.com/news/i...-and-granite-rapids-architecture-xeon-roadmap https://www.anandtech.com/show/2003...etails-granite-rapids-and-sierra-forest-xeons).


##############################
foofoobar schrieb:
Was macht Windows da eigentlich anders und komplizierter als Linux?
Wenn Treiber samt Firmwareblob in Linux mainline enthalten sind, dann haben die Kernelmaintainer die Finger auf der Codequalität und Kompatibilität zu den APIs des Kernels. In der Regel ist das eine recht strikte Qualitätssicherung, die Microsoft bei extern entwickelten Treibern nicht hat. Bei Treibern von Dritten ist es bei Linux und Windows dann teils recht durchwachsen, wie gut Qualität ist. Teils wird das Leiden im Vergleich unter Linux sogar größer. Denn wo Microsoft APIs im Kernel wie Userspace versucht sehr lange zu pflegen, gibt es diese Versuch bei Linux erst gar nicht. Nur APIs die in Richtung Userspace exponiert sind, sind heilig. Alles andere wird bei Bedarf geändert und es wird keine Rücksicht genommen auf irgendwelche Treiber/Module die nicht in mainline gepflegt werden.

Und die Hacks im Kernel, die teils dazu dienen mit den Besonderheiten von CPUs, Mainboards und sonstiger Peripherie umzugehen sind sehr vielfältig. Irgendwelche Windowstreiber, die vom Mainboardanbieter angepasst werden sind im Zweifelsfall ähnlich angepasst.
 
Piktogramm schrieb:
eine recht strikte Qualitätssicherung, die Microsoft bei extern entwickelten Treibern nicht hat.

Microsoft hat schon eine strikte Qualitaetssicherung, die aber anders funktioniert. Die haben (seit ca. 20 Jahren) eine statische Analyse von Treibern mit Hilfe von Model Checking, die bestimmte Eigenschaften des Treibers zu beweisen versucht. Bei Erfolg kriegt der Treiber dann eine WHQL-Signatur von MS, und man kann sein Windows so einstellen, dass es nur WHQL-signierte Treiber installiert. Und wenn man eine Erweiterungskarte mit einem WHQL-Sticker kauft, sollte man einen WHQL-Treiber mitbekommen. Wobei allerdings die Kunden oft die neuesten Grafikkartentreiber gegenueber den WHQL-Treibern bevorzugen.
 
Piktogramm schrieb:
@Volker Vielleicht habe ich es überlesen, aber bei den P-Cores steht eine Entwicklung nicht im Artikel. Die FPU Pipeline wird wohl deutlich verkürzt. Derzeit 4..5 Takte auf geplant 3 Takte bzw. StStufen.
Ja, ich kenn auch noch paar mehr Details zu Redwood Cove, aber sie darf ich nicht sagen. So geil wie es dargestellt wird durch diese Aussage ist es nämlich nicht ..

Und was sich THG bei SRF ausdenkt stimmt auch nicht. Das sind nicht 3 Dies mit je 48 Kernen, das wäre total winzig. Denn wie man ja weiß sind 4 E Cores mit Anhang so groß wie ein P Core. Also wär das quasi nur ein 12Core Die.. zu klein und verschwendet. Denn bei Die zu Die verliert man auch immer bissel Leistung und Latenz geht hoch.
 
  • Gefällt mir
Reaktionen: sioh und Piktogramm
mae schrieb:
Microsoft hat schon eine strikte Qualitaetssicherung, die aber anders funktioniert. Die haben (seit ca. 20 Jahren) eine statische Analyse von Treibern mit Hilfe von Model Checking, die bestimmte Eigenschaften des Treibers zu beweisen versucht. Bei Erfolg kriegt der Treiber dann eine WHQL-Signatur von MS, und man kann sein Windows so einstellen, dass es nur WHQL-signierte Treiber installiert. Und wenn man eine Erweiterungskarte mit einem WHQL-Sticker kauft, sollte man einen WHQL-Treiber mitbekommen. Wobei allerdings die Kunden oft die neuesten Grafikkartentreiber gegenueber den WHQL-Treibern bevorzugen.
Und wie konnten Treiber von FTDI die von MS zertifiziert wurden in voller Absicht Hardware unbrauchbar machen?
 
  • Gefällt mir
Reaktionen: Piktogramm
@mae
Das was Microsoft an QS an der Stelle treibt sichert ein Minimum an Qualität. Da schaut im Regelfall Niemand auf den Code und bewertet grundlegend, das Konzept, Architektur und Implementierung. Was jedoch zwangsläufig passiert, wenn Code in den Linuxkernel fließt.
Wobei das nicht heißen soll, dass unter Linux alles super ist. Es gibt da genug Baustellen. Die Qualität von Binärblobs als Treiber schwankt dann genauso wie unter Windows. Von "Geht so" bis "ich kauf neue Hardware mit anderem Silizium drauf" ist alles dabei.

############
@Volker
Naja nüchterner Gedanken dazu:
1. 3 stufige FPU für einige, aber nicht alle Operationen
2. Es hängt zwischen Decode und FPU ja noch ne ganze Menge an Reorder/Sheduling. Eine kürzere FPU ist also nur ein Teil vom Backend und die Verkürzung der FPU ist damit relativ gesehen deutlich kleiner als der Schritt von 4..5 auf 3..n.
3. Kürzere Pipelines bringen verringern "nur" die Latenzen. Ist also vor allem sinnvoll, wenn die Pipelines leer laufen bzw. verworfen werden müssen, weil es Abhänigkeiten bzw. falsch vorhersagbare Sprünge gibt.

Unterm Strich kommt es also stark auf den laufenden Code bzw. die berechneten Daten an und ich würde 0..10% gesteigerte IPC erwarten.
Eine 3stufige FPU ist Imho dennoch beeindruckend.
 
Piktogramm schrieb:
Wobei das nicht heißen soll, dass unter Linux alles super ist. Es gibt da genug Baustellen. Die Qualität von Binärblobs als Treiber schwankt dann genauso wie unter Windows. Von "Geht so" bis "ich kauf neue Hardware mit anderem Silizium drauf" ist alles dabei.
Mit fällt da eigentlich nur noch ASM, Veritas und Nvidia ein. Wobei NV ja von den Kernel-Blobs weg geht.
Piktogramm schrieb:
Naja nüchterner Gedanken dazu:
1. 3 stufige FPU für einige, aber nicht alle Operationen
2. Es hängt zwischen Decode und FPU ja noch ne ganze Menge an Reorder/Sheduling. Eine kürzere FPU ist also nur ein Teil vom Backend und die Verkürzung der FPU ist damit relativ gesehen deutlich kleiner als der Schritt von 4..5 auf 3..n.
3. Kürzere Pipelines bringen verringern "nur" die Latenzen. Ist also vor allem sinnvoll, wenn die Pipelines leer laufen bzw. verworfen werden müssen, weil es Abhänigkeiten bzw. falsch vorhersagbare Sprünge gibt.
Kurze Latenzen sind natürlich immer schick, aber bei typischen FPU-Code dürfte wohl der Throughput wichtiger sein.
 
AH ok stimmt Intel hat immer mehr Decode schon gehabt als AMD.Ab wann bringen breitere Decode nichts mehr bzw ab wann bringen die was?
Weil je breiter desto aufweniger kann die Anwendung sein.Nur was passiert wenn die Struktur eher einfach gehalten ist oder es eh alles im Decoder schon platz hat.Verpufft dann die Steigerung am Ende dann?
 
foofoobar schrieb:
Und wie konnten Treiber von FTDI die von MS zertifiziert wurden in voller Absicht Hardware unbrauchbar machen?

Wo finde ich was dazu? Ich gehe davon aus, dass die Pruefung von MS unabsichtliche Fehler finden soll und nicht gegen absichtliche Angriffe entwickelt wurde. Warum sollte ein Hardware-Hersteller einen Treiber bauen, der mit voller Absicht die Hardware unbrauchbar macht?
 
mae schrieb:
Zur Marktsegmentierung. Die wollen fuer Windows Server einfach mehr verlangen als fuer Windows Home.
Es nervt trotzdem wenn für ein und den selben Chip auf unterschiedlicher Rest-Hardware unterschiedliche Treiber benötigt werden, insbesondere weil es technisch komplett unnötig ist und künstlich reinprogrammiert wurde und kein zusätzlicher Nutzen dadurch erzeugt wird.
 
Zuletzt bearbeitet:
foofoobar schrieb:
Kurze Latenzen sind natürlich immer schick, aber bei typischen FPU-Code dürfte wohl der Throughput wichtiger sein.
Meinst du mit Durchsatz also wieviele Arbeiten bzw Aufgaben gleichzeitgen Verarbeitet oder Vorgearbeitet werden kann damit?
 
mae schrieb:
Wo finde ich was dazu? Ich gehe davon aus, dass die Pruefung von MS unabsichtliche Fehler finden soll und nicht gegen absichtliche Angriffe entwickelt wurde. Warum sollte ein Hardware-Hersteller einen Treiber bauen, der mit voller Absicht die Hardware unbrauchbar macht?
Frag das mal besser FTDI.
Viel Spaß beim lesen: https://www.google.com/search?q=ftdi+bricking
Ergänzung ()

latiose88 schrieb:
Meinst du mit Durchsatz also wieviele Arbeiten bzw Aufgaben gleichzeitgen Verarbeitet oder Vorgearbeitet werden kann damit?
Kapitel 9.4 von https://www.agner.org/optimize/optimizing_assembly.pdf
bzw.: https://www.google.com/search?q=instruction+latency+and+throughput
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: mae
Zurück
Oben