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

Volker

Ost 1
Teammitglied
Registriert
Juni 2001
Beiträge
18.249
Mit dem Sparc M8 schickt Oracle ein neues Monster in die Pipeline, welches primär für die eigenen Datenbank-Anwendungen konzipiert ist. Mit 32 Kernen und daraus resultierenden 256 Threads sollen bei Taktraten von 5 GHz massive Leistungsverbesserungen gegenüber dem Vorgänger erzielt werden.

Zur News: Oracle Sparc M8: 32 Kerne und 256 Threads bei 5 GHz in 20-nm-Fertigung
 
Oracle hat ja keine x86 Lizenz
 
Wer ist noch mal Intel ?

32 Kerne 256 Threads !!!
 
@roterhund07 mit dem unterscheid, dass intel keine 5Ghz schafft der Sparc M8 aber schon.
 
@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.
 
@roterhund07

Nur das die Sparc CPU, bei 72 Kernen 576 Threads und einen erheblichen Takt hätte.
 
Zuletzt bearbeitet:
@ottoman nun da wir aber nun mal nur die specs vergleichen können bleibt einem nur das. Mal ganz davon ab das der Sparc M8 mit Sicherheit schneller ist in dem für was er gemacht wurde als der Intel. Sonst würden sie sicher keine eigene CPU bauen. Ist ja nicht als sei das besonders günstig.
 
@ Haffke
Der SPARC Prozessor muss nicht zwangsläufig in bestimmten Aufgaben schneller als die Konkurrenz sein. Wahrscheinlich ist das schon, ja. Aber es gibt auch genug Firmen, deren Software nur auf SPARC läuft und die keine Wahl haben, weil eine Migration auf x86 viel zu teuer wäre. Vielleicht gibt es ja zeitnah mal irgendwo Testberichte, würde mich jedenfalls sehr interessieren.

Edit: Fujitsu stellt auch noch SPARC CPUs her, sehe ich gerade
 
Zuletzt bearbeitet:
Was genau sind das für CPUs ?
X86 ist es wohl nicht.
PowerPC ?
ARM ?
Dieses Antike Ding von Motorolla wo mir der Name nicht einfällt ?
Oder was ganz eigenes ?
 
Wie funktioniert eigentlich 1 Kern 8 Threads? Wie macht ein Kern pro Taktzyklus 8 Rechnungen?
Von A nach B und zurück ist 1 Takt soweit ich weiß. (Bildlich gesprochen)

1 Kern, 1 Thread = von A nach B wird gerechnet, zurück passiert nichts
1 Kern, 2 Threads = von A nach B wird gerechnet, zurück von B nach A auch
1 Kern, 8 Threads = ?

Technisch auf jedenfall interessant der/die SPARC.
 
Pizza! schrieb:
Wie funktioniert eigentlich 1 Kern 8 Threads? Wie macht ein Kern pro Taktzyklus 8 Rechnungen?
Von A nach B und zurück ist 1 Takt soweit ich weiß. (Bildlich gesprochen)

Diese Erklärung bringt dir in diesem Kontext nichts. Prozessoren haben eine sogenannte Pipeline ("Fließband"), in der die Befehle bearbeitet werden. Dabei gibt es je nach Prozessor unterschiedlich viele Arbeitsschritte. Die Befehle kommen vorne rein und hinten sind sie fertig ausgeführt. Pro Takt bewegen sich die Befehle einen Arbeitsschritt weiter. Bearbeitet der Prozessor einen Befehl pro Taktzyklus, dann heißt das, dass bei jedem Takt ein Befehl am Ende der Pipeline ankommt.

Das mit dem HyperThreading oder Symmetric Multi Threading heißt nun, dass die Pipeline so breit ausgeführt ist, dass das ggf. mehr als ein Befehl nebeneinander drauf passt. Es gibt Befehle, die mit kleineren Datentypen als andere, oder die nur ein Argument haben statt zwei. Deswegen passt ggf. von den "breitesten" Befehlen nur ein einziger aufs Fließband, aber von den einfachen mehrere. HyperThreading ist nichts anderes als der Versuch, "auf gut Glück" mehr als einen Befehl auf das Fließband zu packen, und dann zu hoffen, dass er bis ans andere Ende nicht runter geschmissen werden muss, weil bei allen Arbeitsschritten genug Ressourcen verfügbar sind, um alle Befehle auf einmal zu bearbeiten.

Es spricht erst einmal nichts dagegen, auch mehr als zwei Befehle gleichzeitig drauf zu legen, vor allem,wenn der Prozessor eine sehr große Bandbreite zwischen den "schmalsten" und den "breitesten" Befehlen hat.

Das ist jetzt alles sehr vereinfacht, und es fehlen viele Feinheiten, aber so grob kann man sich das vorstellen.
 
Es gab doch glaube auch schon Opterons vor Jahren die ihre Thread Zahl vervierfacht haben, kommt halt auf die Anwendung an. Bei virtuellen Maschinen ist das sicher von Vorteil, wenn man bei 8 realen 32 Threads hat, da ja selten alle den Prozessor voll auslasten würden, kann er so durch die vielen aneinander gereihten Aufgaben effizient arbeiten. Bringt ja nix wenn der Prozessor die meiste Zeit im Idle steht.
 
Schickes Stück CPU-Technik, aber halt absolute Nische.

Wenn die Zielkunden andere Probleme haben als Hardwarekosten, weil die darauf laufende Software samt der Heerschar von hochbezahlten Anwendungsentwicklern und DBAs ohnehin den weitaus größeren Posten im IT-Budget ausmachen, kann man sich halt fast grenzenlos in der CPU-Entwicklung austoben. :cool_alt:
 
aus reinem Interesse, was ist das Einsatzgebiet solcher Prozessoren? Selbst bei den Supercomputern liest man wenn mich meine erinnerung nicht komplett trübt ja meist von Intel oder AMD.

Spontan könnte ich mir jetzt vorstellen dass das für etwas wie einen Kafka-Server (banal, ein Server für Message-Queues) ganz nett sein könnte. Allerdings hab ich keine Ahnung inwiefern die Topics auf eigene Threads verteilt werden bzw. verteilt werden können, nichts desto trotz wäre dort viel Parallelisierung sicher hilfreich und der hohe takt sicher auch nicht falsch.
 
Vielleicht genau das Richtige um eine langsame statt einer sack langsamen Teamcenter PLM Datenbank zu erhalten. Mich würde interessieren was man erreichen kann und wie schnell es werden kann.
 
7hyrael schrieb:
aus reinem Interesse, was ist das Einsatzgebiet solcher Prozessoren? Selbst bei den Supercomputern liest man wenn mich meine erinnerung nicht komplett trübt ja meist von Intel oder AMD.

Spontan könnte ich mir jetzt vorstellen dass das für etwas wie einen Kafka-Server (banal, ein Server für Message-Queues) ganz nett sein könnte. Allerdings hab ich keine Ahnung inwiefern die Topics auf eigene Threads verteilt werden bzw. verteilt werden können, nichts desto trotz wäre dort viel Parallelisierung sicher hilfreich und der hohe takt sicher auch nicht falsch.
Es wird ja bereits im Text erwähnt. Für Datenbanken oder einfach alles was nicht extrem viel Leistung braucht aber viele Zugriffe bekommt. Also was Zeit relevant ist und parallel laufen muss.
 
Zurück
Oben