News Oracle Sparc M8: 32 Kerne und 256 Threads bei 5 GHz in 20-nm-Fertigung

Nai schrieb:

Tur mir leid aber das ist irgendwo zwischen ungenau und falsch, SMT zunächst nichts mit SIMD bzw logischer/physikalischer SIMD-breite zu tun. Die Grundidee hinter SMT eine andere: Mehrere Threads teilen sich ein und die selben Rechenwerke. Dadurch kann, sofern ein bestimmter Thread gerade keine Aufgabe für ein bestimmtes Rechenwerk hat, mit einer gewissen Wahrscheinlichkeit, ein anderer Thread dem Rechenwerk eine Aufgabe geben, wodurch sich wiederum die Auslastung der Rechenwerke erhöht. Je mehr Threads ein SMT Prozessor also gleichzeitig ausführen kann, umso größer ist auch diese Wahrscheinlichkeit bzw die darin resultierende Auslastung des Rechenwerks.

Zum Vergrößern anklicken....

Dass es ungenau ist, hatte ich ja selbst geschrieben. Natürlich bezieht es sich letztendlich auf die Verfügbarkeit bestimmter Ressourcen im Prozessor, allerdings müssen die Threads immer durch die Verarbeitungspipeline. Ein Befehl kann die gerade von einem anderen Befehl nicht benötigte Ressourcen nutzen. Oder es gibt teilweise auch mehrfach vorhandene Ressourcen für einen Schritt in der Pipeline. Bei letzterem handelt es sich allerdings schon wieder um ein mildes Abweichen vom reinen Hyper Threading, denn wenn die Ressource mehrfach verfügbar ist, dann ist man schon auf "halbem Weg" zu einem echten zweiten Kern. Und es kommt hier aber eben auch zu den "verschiedenen Breiten". Teilweise kann eine Ressource entweder eine 32 Bit breite Anwendung bearbeiten oder parallel auch zwei zu je 16 Bit. Man kann das auch umdeuten dazu, dass es zwei Einheiten gibt, die man auch kombinieren kann für doppelte Breite. Und dann kommt weiterhin hinzu, dass die Befehle immer noch durch die Pipeline müssen. Man kann einen darin befindlichen Befehl ggf. einen Schritt verzögern (PAUSE instruction), aber beliebig lange kann man nicht auf die Ressource warten.

smalM schrieb:

Es geht nicht um einen Chip-Vergleich.
Es gab mehrere gute Gründe für AMD und Nvidia, den 20nm-Prozeß auszulassen, fast alle wirtschaftlicher Natur.
Noch ein Jahr bei 28nm zu bleiben war aber damals sehr unpopulär. Also hat man lieber das Märchen vom "der 20nm-Prozeß taugt nix" erfunden, man dachte wohl "das lohnt sich für uns nicht" käme nicht so gut an...

Zum Vergrößern anklicken....

Das schließt sich jetzt ja nicht aus. Wenn man 20nm noch nicht im Griff hat und 28nm fast perfekt optimiert hat, dann lohnt sich der 20nm Prozess nicht. Weder wirtschaftlich, noch für den Kunden.
Genauso wie es jetzt mit 14nm ist, den es schon im dritten Aufguss gibt. Und 10nm sich verzögert.

ottoman schrieb:

@Haffke
Ich dachte von der "Prozessor X hat mehr MHz als Prozessor Y und ist damit automatisch besser" Denkweise haben wir uns schon länger verabschiedet? Anscheinend nicht.

Zum Vergrößern anklicken....

Die wurde kürzlich ersetzt durch "Prozessor X hat mehr Kerne/Threads als Prozessor Y"... Die effektive Leistung interessiert heute nicht mehr

Nai schrieb:

Tur mir leid aber das ist irgendwo zwischen ungenau und falsch, SMT zunächst nichts mit SIMD bzw logischer/physikalischer SIMD-breite zu tun. Die Grundidee hinter SMT eine andere: Mehrere Threads teilen sich ein und die selben Rechenwerke. Dadurch kann, sofern ein bestimmter Thread gerade keine Aufgabe für ein bestimmtes Rechenwerk hat, mit einer gewissen Wahrscheinlichkeit, ein anderer Thread dem Rechenwerk eine Aufgabe geben, wodurch sich wiederum die Auslastung der Rechenwerke erhöht. Je mehr Threads ein SMT Prozessor also gleichzeitig ausführen kann, umso größer ist auch diese Wahrscheinlichkeit bzw die darin resultierende Auslastung des Rechenwerks.

Zum Vergrößern anklicken....

und ich dachte schon, dass ich SMT komplett falsch verstanden hatte, weil mir das mit der Pipeline so unbekannt in diesem Kontext vorkam^^

7hyrael schrieb:

aus reinem Interesse, was ist das Einsatzgebiet solcher Prozessoren?

Zum Vergrößern anklicken....

Vermutlich primär fürs Weiterbetreiben von Slowlaris-Altlasten bei Versicherungen u.ä.

Hardware stirbt nach paar Jahren. Um die olle Software, die niemand mehr auf ein anderes System portieren will, weiterbetreiben zu können, brauch man neue, kompatible Hardware und ist bereit dafür Mondpreise zu zahlen. Sun hat ja seinerzeit auch große Rechner verkauft (Sun Ulta Enterprise 10k, später Sun Fire 12k/15k), Oracle später vermutlich auch.

Das gleiche Phänomen sehen wir bei Intel-Itanium: Da gibts auch vor dem endgültigen Tod nochmal gepimpte CPUs. SPARC ist allerdings viel weiter verbreitet als Itanium.

PHuV schrieb:

Ich habe in den 2000ern mal eine Analyse machen müssen, weil die Sun-Server mit einem C-Programm immer langsamer liefen als vergleichbare PCs mit AMD und Intel-Prozessoren. Fakt war, daß die Sparcs damals trotz höherem Takt ca. 30% langsamer waren.

Zum Vergrößern anklicken....

Sicher, dass du dich da richtig erinnerst? Sparcs hatten doch vergleichen mit der Konkurrenz eigentlich immer nur gemütlichen Taktraten zu bieten. Sie waren pro Takt gar nicht so schlecht, aber insgesamt kam zu wenig rüber. In der 32-bit-Ära waren sie _richtig_ lahm. Ab den 64-Bittern der 2. Generation (UltaSPARC II) war Sun immerhin bischen näher am Rest der Welt. Der Vergleich Server<->PC hinkt natürlich, wenn man sich nur die reine Rechenleistung anschaut. Bei Servern ist oft I/O-Leistung gefragt, wo normale PC-Technik traditionell mau ist.

Sparcs waren jedenfalls nie Giganten in Sachen Rechenleistung. Sun hat die Dinger verkaufe können, weil das OS vergleichsweise (zu AIX/HP-UX/Irix/whatever) gut war und die Kisten zwar teuer aber nicht sooo teuer waren.