News Sonoma: Oracles Low-Cost-SPARC-CPU mit acht Kernen und 64 Threads

[Volker]

Für das Enterprise-Marktumfeld hat Oracle auf der Hot Chips 27 den Low-Cost-Ableger mit dem Namen Sonoma vorgestellt. Dieser versteht sich als ein Viertel so großer Bruder des M7, mit acht Kernen und jeweils bis zu achtfachem Threading in 20-nm-Fertigung soll das Modell jedoch weiterhin eine hohe Leistung liefern.

Zur News: Sonoma: Oracles Low-Cost-SPARC-CPU mit acht Kernen und 64 Threads

 

[yummycandy]

Sparc-Systeme waren ja immer für hohe I/O optimiert. Wo will man die abgespeckte Version einsetzen? Für mittelständische Unternehmen inkl. deren Datenbanken?

 

[raph]

Ach, die guten alten Sparc....

Ich hatte mal ne SunSparc4 zu Hause (Mit Ultraschwerem Monitor, weil der einen proprietären Stecker hatte -.-). Solaris ist damals echt ein super Unix gewsesen.

Allerdings sind die meisten Kunden schon 2005 ernsthaft dran gewesen, zu x86 mit Linux zu portieren. Hier verdienen Red Hat und SuSE ihr Geld. Solaris auf Sparc ist ja mittlerweile echt eine Nische in der Nische geworden.
Eigentlich hab ich die Plattform für tot gehalten. Man lernt nie aus.

 

[MuppetsGonzo]

@Schiddy: danke für OT ^^

... bezüglich Crysis ... wo liegen die Sparc CPUs bisher bei Specfp und Specint? (ich weis leider nicht, wonach ich bei Sparcs nach Namen suchen soll.) mit PCIe3.0

wie klappt eigentlich dieses achtfache "hyperthreading" oder wie das bei SUN heißt? Bei Intel hat man ja nach fp und int aufgeteilt; hat bei dem Sparc jeder Kern 4fp und 4int Aufgaben parallel möglich?

 

[Haldi]

Ich kapier das mit DDR4 nicht.
Folie 4 steht deutlich direct attached DDR4 memory. Heisst das nu einfach der Speicherncontroler war beim T5 noch nicht im CPU drin?

 

[TenDance]

jetzt will ich aber echt wissen ob da crysis drauf rennt

Ganz einfach: kein x86, kein Crysis! Oder kennst Du einen x86 Emulator für SPARC?

@Redaktion: wenn ihr solche, sagen wir mal recht speziellen Themen, auf die frontpage holt und dann auch noch im Artikel mitteilt dass selbst der Hersteller dieses Chips knapp 80% der von ihm verkauften Systeme auf x86-Basis(Intel) sind, stellt sich dem geneigten Leser doch die Frage: was ist ein SPARC? Was macht der anders als mein AMD/Intel (x86) oder mein Handy (ARM) und warum lohnt sich das da noch zu entwickeln?

Derlei wäre doch mal einen Artikel wert, welchen ihr bei solchen News einfach weiterverlinken könntet.

 

[DerGoblin2k]

Oder kennst Du einen x86 Emulator für SPARC?

Bochs

 

[TenDance]

Braucht Bochs nicht einen unixoiden Unterbau auf dem Windows dann in ner Box läuft? Und darauf dann ein Spiel spielen? Ich glaub da bräuchte es noch die ein oder andere SPARC-Generation
Tut mir Leid, ich bin seit meinem Crusoe etwas ernüchtert was die Übersetzung von Befehlen und deren Performanz anbelangt

 

[DerGoblin2k]

Man könnte mit Qemu ein Windows Image erstellen, welches man dann mit Bochs zum laufen bekommt. Natürlich wird Crysis da nicht darauf laufen. Aber Du fragtest in erster Linie nach einem X86-Emulator für SPARC.

Edit: So klappt jedenfalls mit Windows XP auf Androidgeräten.

 

[Tekpoint]

Der Threadwahnsinn hat auch hier begonnen ^^ ich mag lieber echte Kerne als das virtuelle Zeug.

 

[Bully|Ossi]

Das mit den vielen threads macht aber Sinn, da sonst die CPU wohl nur schwer ausgelastet werden kann. So kann man viele kleine Berechnungen parallel laufen lassen, die in Summe dann für volllast sorgen. Ist also effizienter.

Würde mir auch wünschen das z.b. ein i7 auch statt 4 dann 8 virtuelle Kerne hat. Das würde dann ggf. auch mal die Optimierung für mehr threads vorantreiben..

 

[Piktogramm]

@Bully|Ossi

Es kommt stark auf den Anwendungsfall an, wie Programme mit Hyperthreading skalieren. Bei einem sehr großen Teil an Anwendungssoftware skaliert schon einfaches HT nur in geringem Maß. Da lohnen noch mehr Threads je Kern schlicht nicht. Entsprechend finden sich Prozessoren mit mehr als 2 Threads pro Kern meist nur in CPUs für Server.

 

[S.Kara]

Wie sieht es denn mit dem Performancegewinn aus bei 8 Threads pro Kern?
Ich glaube bei 2 Threads gibt der 2. so um die 30-40%?
Würde mich freuen wenn hier jemand halbwegs verlässliche Infos posten könnte wie es mit der Performance bei 2/4/8 Threads pro Kern aussieht.

 

[VikingGe]

Das liegt aber weniger daran, dass durchschnittliche Anwendersoftware die einzelnen Kerne so toll auslastet, sodass HT nicht skalieren kann, sondern eher daran, dass durchschnittliche Anwendersoftware genau einen Kern nutzt und deshalb schon damit überfordert ist, einen Pentium effizient auszulasten.

Dass sich mehr als zwei Threads pro Kern bei Intel-Architekturen lohnen würden, wage ich dennoch zu bezweifeln, dafür müsste man schon massiv die Kerne vergrößern. Irgendwann limitiert auch einfach das Backend, also die Ausführungseinheiten.

 

[Piktogramm]

@S.Kara

Kommt sehr auf die Anwendung drauf an. Bitte Post weiterlesen


@VikingGe

JAIN!

So binär wie deine Aussage daherkommt ist auch die digitale Welt nicht.
Es gibt allerhand Software, bei der es nicht lohnt mehrere Threads zur Laufzeit vorzusehen, da bei solcher Software der Overhead des Threadhandlings mehr Resourcen braucht als die Aufgaben mittels eines einzelnen Threads abzuhandeln.

Genauso gibt es Anwendungen die mittels multithreading sehr gut skallieren, solang sie auf nativen Kernen laufen und die Gewinne über HyperThreading sind da mitunter gering, da die Threads die verfügbaren Ressourcen der nativen Kernen bereits sehr gut auslasten. Hier helfen moderne Kompiler und div. Befehlserweiterungen. Als ich vor einer Weile ein bisschen multithreaded Kram gelernt habe, hat das nutzen von 4 Threads zu 8 Threads ~10% Leistungvorteil gebracht (4Kerne, 8Threads) und nach deaktivieren von SMT waren es noch ~5% geringere Laufzeit bei 8 Threads im Vergleich zu 4 Threads. Einfaches SMT hat da kaum etwas gebracht und ein höherrangiges SMT hätte wahrscheinlich keine Verbesserung außerhalb der Messungenauigkeit geliefert. Software die derart optimiert ist gibt es durchaus.
Dieses Verhalten sollte auf die meisten Programme zutreffen, die hauptsächlich rechnen, ohne auf I/O bzw. andere Threads warten zu müssen.


Genauso gibt es aber auch Software die von SMT ganz wunderbar profitiert, Erfahrungsgemäß bringen viele Threads und SMT vor allem etwas, wenn die Threads immer mal wieder auf I/O oder aber andere Threads warten müssen, was für viele reale Programme gilt. Fälle in denen mehr als 2Threads je Kern seitens der CPU etwas bringen ist bei Endanwendern aber doch recht selten.

Ausnahme sind da natürlich Benchmarks! Die verhalten sich mitunter recht putzig und oft ist nicht dokumentiert was da wirklich stattfindet und wieso sie sich verhalten wie sie sich verhalten.
Auch gibt es Software die einfach Müll ist.

 

[Simon]

Dass sich mehr als zwei Threads pro Kern bei Intel-Architekturen lohnen würden, wage ich dennoch zu bezweifeln, dafür müsste man schon massiv die Kerne vergrößern. Irgendwann limitiert auch einfach das Backend, also die Ausführungseinheiten.

Wenn es sich nicht lohnen würde, hätte der kommende Xeon Phi x200 (Knights Landing) wohl kaum 4-way SMT. Nur aus Spaß hat Intel das bestimmt nicht rein gebastelt.

Und ein Silvermont-Kern des Xeon Phi ist im Vergleich zu den richtigen "Big-Cores" der normalen Xeon-Linie (Haswell-EP) abgesehen von den zwei VPUs gerade zu simpel aufgebaut.

 

[Piktogramm]

@Simon

Die Xeon Phi werden in der Regel aber auch völlig andere Workloads bearbeiten als typische Desktop Rechner. Ist ja nicht nur die CPU Architektur, sondern auch die Software, die einen gehörigen Einfluss darauf hat, inwieweit SMT sinnvoll ist.

 

[mensch183]

Sparc-Systeme waren ja immer für hohe I/O optimiert.

Oder ohne Schönreden: Die I/O-Leistung war der Konkurrenz nicht ganz so weit hinterher wie die Rechen- und ggf. Grafikleistung. MMn war das passable OS der einzige Vorzug von Sparcs zu Sun-Zeiten.

Mit Ultraschwerem Monitor, weil der einen proprietären Stecker hatte

13W3? Hatten damals die Rechner von vielen verschiedenen Herstellern - allerdings nicht alle gleich belegt. Die Belegung war also durchaus proprietär. ^^

 

[Kowa]

Diese 8-Thread-Cores sind m.M.n. der größte Mist. Der IT-Abteilung hat man diesen Unsinn offenbar verkauft und nun versuchen die das wie sauer Bier an die Projekte zu vermieten (T3, T4, T5). Jedesmal heißt es: "die neuen Server sind aber viel schneller".

Da stecken z.B. 2x8-Core-CPUs drin; 2x8x8= 128Threads. Aus denen werden virtuelle Server geschnitten. Da kann dann tatsächlich Solaris oder Linux etc. vollkommen getrennt laufen. Man sieht dann z.B. 8 Cores, aber es sind nur 8 Threads mit der Leistung eines (enorm langsamen) Cores. Mir fällt kein Szenario in einem Wirtschaftsunternehmen ein, wo man sowas braucht. Uns nervt dieser Mist nur maßlos an, wenn ein java-Webserver 5-10 Minuten zum Start braucht, man muß sich das vorstellen wie Petium-III.
Vlt. gibt es an einer Uni ja einen spleenigen Mathematiker, der 128 Threads derat bestücken kann, daß nicht alle Threads an die gleiche CPU-Komponente nutzen wollen. Ein einfacher Test mit gzip erreicht nach meiner Messung 1/4 der Geschwindigkeit eines i3.

Viel interessanter ist die Sparc64-X-CPU. Die Architektur ist viel eher auf der Höhe der Zeit: integrierter Speichercontroller, 16 Cores (Duo-threded) teilen sich 22MB Cache auf dem gleichen Chip. Und 3,2GHz sind bei einem 16-Core-Xeon auch nicht gerade üblich.

Oracle, als Datenbank-Hersteller, will damit die Großkunden auf die eigenen Server locken. Der Befehlssatz ist angeblich speziell für den Datenbankbetrieb optimiert. IBM hat vor Dekaden mit dieser Strategie viele Kunden gewonnen (Server+Datenbank aus einer Hand).

 

[Piktogramm]

@Kowa

Was du beschreibst sind einfach VM Guests die sich auf dem Host aufgrund von überbelegten Ressourcen in die quere kommen. Mit SMT hat das nichts zu tun. Denn so ne depperte Überbelegung bekommt man auch ohne SMT hin. Auf einem 4Kerner ohne SMT kann man auch 4VMs mit je 4 zugewiesenen Kernen laufen lassen. Den Rest erledigt der Sheduler vom Host recht gut. Wird erst Kacke, wenn die Guests mehr Rechenzeit brauchen als in Summe zur Verfügung steht.
Oder kurz: Das was du beschreibst ist ne beschissene Config ein Reinform