News IBM: Neuer Power7+ bis zu 20 Prozent schneller als Vorgänger

[smalM]

Die Kosten der Hardware spielt da, wo POWER7-Systeme eingesetzt werden, meist eine untergeordnete Rolle, da die Kosten der Software um eine Größenordnung darüber liegt.

Und bei den Kosten der Software ist oft die Anzahl der realen Cores ausschlaggebend, ein hoher Durchsatz pro Core also erwünschenswert. Der Preis pro Core darf da ruhig deutlich höher sein als bei X86.

 

[new-user]

Das einzige, wo sie mir ab und zu noch auffallen sind elektronische Registrierkassen, auf denen das IBM Logo drauf ist.

Diese Sparte wurde neulich erst auch abgestoßen, ging an Toshiba.

 

[Locuza]

Frag mich wie sich die Pro-MHz Leistung bei vergleichbaren Aufgaben mit aktuellen x86-Prozessoren hält... 5,5 GHz sind ja schon 'ne Hausnummer...

Sandy-Bridge hat ungefähr eine ST IPC Performance (bezogen auf Integer) , die 30% über einem Power 7 liegt.
Bezogen auf SPECint 2006 Benchmark, weil es schwer ist direkte vergleiche zu ziehen. Power ist aber auch nicht für Single-Thread Anwendungen konzipiert, was man bei den Multithreading Benchmarks sehr gut sehen kann.

http://www.tecchannel.de/server/prozessoren/2016541/test_die_schnellsten_cpus_im_benchmark_vergleich/index3.html

 

[ice-breaker]

@Locuza: PowerPC und der hier genannte Power7 Prozessor sind aber komplett verschiedene Dinge Sie klingen ähnlich, sind es aber nicht.

 

[Locuza]

@Locuza: PowerPC und der hier genannte Power7 Prozessor sind aber komplett verschiedene Dinge Sie klingen ähnlich, sind es aber nicht.

Danke für die Korrektur, aber komplett verschiedene Dinge sind das auch nicht

 

[Mumpitzelchen]

Im Gegenteil: Ohne RISC Prozessoren wären wir immer noch bei 32bit Singlecores wie dem Pentium oder dem K6 (beim Pentium gab es immerhin noch Boards mit 2 Sockeln).

Und ohne ARM keine Smartphones.

Der K6 war schon eine RISC CPU. K6 hat nach aussen nur CISC gespielt, so wie alle x86 CPUs heute. Der originale Pentium war immer noch CISC.

 

[[F]L4SH]

Kann mal einer verständlich den immer wieder erwähnten Unterschied zwischen RISC und CISC erklären? Beim üblichen Wikipedia habe ich da noch nicht vollkommen die Unterschiede verstanden. Vorallem, weil Chaosbla keine Gelegenheit auslässt über CISC zu lästern.

Bin ja schon froh, dass ich den Unterschied zwischen In Order und Out of Order verstanden habe, oder mir den Sinn einer FPU erarbeiten konnte. Als Laie, der nichts mit dem Thema in der Tiefe zu tun hat, habe ich einfach so meine Schwierigkeiten mit den Grundbegriffen.

 

[ice-breaker]

Neija RISC (Reduced Instruction Set Computing) soll weniger Instruktionen als CISC (Complex Instruction Set Computing) haben. Die Idee davon ist einfach, dass ein Prozessor, der weniger Instruktionen hat, leichter zu designen ist und somit simpler und einfach zu optimieren ist.
Das ganze ist aber nun 40 Jahre her und diese echte Trennung wirklich kaum noch vorhanden. Heute gibt es kaum noch RISC und kaum noch CISC, alles bewegt sich da irgendwie mittendrin.
Der Nachteil von CISC sind eben die vielen komplexen Instruktionen bei denen dann eben die Pipelines aufgedunsen sind und und und.

Aber: Man schaue sich einen heutigen Intel x86 an, mit RISC hat das auch nichts mehr am Hut. Oder gar die aktuellen Bulldozer mit den AVX-Instruktionen, immer mehr Instruktionen direkt im Prozessor damit in einer Operation mehr gemacht werden kann.
Also der RISC/CISC-Unterschied ist imho ein antiquitiertes Modell, beides trifft heute nicht mehr zu und echtes RISC hat man nur noch in Mikrocontrollern, also z.B. die 8 und 16 Bit Teile. Normale Prozessoren sind schon lange CISC.

 

[[F]L4SH]

Wow danke. Das ist gut verständlich und logisch.
Wird nicht ein X86 Prozessor, der eigentlich als RISC beworben wird zum CISC, weil man diesen ganzen unvorstellbar "nutzlosen" Ballast wie 8 und 16 bit, altes SSE und was weiß ich mitschleppt?
Leider kann man im X86 nie und nimmer mehr einen Hardcut machen. Die Kompatibilität wäre futsch und die Geschäftskunden wären nicht nur "not amused" sondern ernsthaft angepisst - man entschuldige die Ausdrucksweise.
Itanium war doch der Versuch eines "kleinen" Hard Cuts als eine 64bit Architektur. Was dann aber an AMD und Microsoft (zum Glück) scheiterte.

 

[Locuza]

X86 war nie ein reiner RISC, sondern zuerst ein CISC Prozessor, welcher heute eher ein Hybrid aus beiden ist.
Zwischen RISC und CISC gibt es aber einige Unterschiede.
Ich zähle nur ein paar oberflächlich auf.

RISC:
- Wenig Befehle, weniger Komplex, das optimieren fällt leichter.
- Befehle können dafür aber auch weniger
- Deutlich mehr Register vorhanden, Speicherzugriffe können oft vermieden werden.
- Die Befehle haben ein einheitliches Format, also die Länge eines Befehls, dadurch können Befehle schneller ausgeführt werden, verbrauchen aber auch mehr Speicherplatz.


CISC:
- Viele Befehle, komplex, optimieren fällt eher schwer.
- Befehle können dafür mehr, bestimmte Aufgaben können überhaupt erst in einem Schritt erledigt werden, somit ist es einfacher Probleme zu lösen, da ein CISC Prozessor einfach mehr Lösungswege beherrscht, die auch umfangreicher ausfallen.
- Weniger Register vorhanden
- Die Befehle haben kein einheitliches Format und werden oft erst in kleine Häppchen geteilt, worauf sie wieder entpackt werden müssen. Nachteil, es dauert länger Befehle aus zu führen, Vorteil es spart Platz, da die Größe Unterschiedlich ausfallen kann.

Man spricht heute weniger von CISC und RISC, da beide Vorstellungen sich immer Stück für Stück mehr vermischt haben. Mittlerweile beherrschen auch RISC Prozessoren komplexere Befehle und auch mehr, weil es sich eben auch bei bestimmten Sachen lohnt.
Heutige X86-Prozessoren zerlegen die Befehle auch in kleine "RISC-Befehle" (micro-op) und haben durch Befehlssatzerweiterungen mit eigenen Registern, auch schon einige Nachteile der prinzipiellen Idee kaschiert.
Dennoch arbeiten sie weiterhin unterschiedlich und die Grundsätzliche Idee bleibt verankert.

 

[Kenneth Coldy]

Nur eine Detailfrage: Ist die geringe Anzahl der Register eine Eigenschaft von CISC oder von x86?

 

[MountWalker]

Also imho sollte bei RISC auf keinen Fall "wenige Befehle" als kriterium genannt werden, da es noch nie wirklich der Fall war, dass RISC-Prozessoren signifikant weniger Befehle hatten. Es ist eine uralte Ableitung aus dem Namen, aber seit jeher, und so stehts deshalb nach ellenlangen Diskussionen auch seit ein paar Jahren in der Wikipedia, bezieht sich das "Reduced" in Reduced Instruction Set Comptuting einzig und allein auf die Länge der Befehle, die gleich sein muss.

Rein von der Anzahl der Befehle unterscheiden sich x86-64 und PPC kaum - aber die Befehlslänge macht den einen Code eben zu einem RISC-Code und den anderen zu CISC-Code.

 

[Locuza]

Nur eine Detailfrage: Ist die geringe Anzahl der Register eine Eigenschaft von CISC oder von x86?

Nach einer starken Trennung zwischen CISC und RISC, ist das eine CISC Angelegenheit, weil es eine Entweder-Oder-Entscheidung ist. Das hat mit den komplexen Befehlen und den Registern an sich zu tun. Ich muss bei vielen und komplexen Befehlen auch angeben, in welchem Register sie gespeichert werden, dann kann man Register noch einmal unterteilen, dann muss ich angeben, welche Untergruppe ich benutze usw. Das kostet alles Speicherplatz, wobei das heute weniger kritisch ist, da wir mit Transistoren praktisch um uns schmeißen können und durch ein RISC-Design Transistoren und Logik eingespart werden kann, weswegen auch mehr Register zur Verfügung stehen und auch notwendig sind, weil mehr Adressiert wird und der Code auch länger dadurch wird, da er gekennzeichnet werden muss.

Also imho sollte bei RISC auf keinen Fall "wenige Befehle" als kriterium genannt werden, da es noch nie wirklich der Fall war, dass RISC-Prozessoren signifikant weniger Befehle hatten. Es ist eine uralte Ableitung aus dem Namen, aber seit jeher, und so stehts deshalb nach ellenlangen Diskussionen auch seit ein paar Jahren in der Wikipedia, bezieht sich das "Reduced" in Reduced Instruction Set Comptuting einzig und allein auf die Länge der Befehle, die gleich sein muss.

Rein von der Anzahl der Befehle unterscheiden sich x86-64 und PPC kaum - aber die Befehlslänge macht den einen Code eben zu einem RISC-Code und den anderen zu CISC-Code.

Doch auf jeden Fall hatten RISC Prozessoren anfangs und sehr wohl auch heute, weniger Befehle, auch wenn das heute weniger stark ausgeprägt ist.
CISC hatte über 2 mal so viele Befehle. Die heutigen X86 Prozessoren haben zwar im Grunde einen RISC-Kern, verstehen aber dennoch noch alle CISC-Befehle.

 

[BeeHaa]

In den "z" laufen keine Power. z sind sozusagen die Server der Bänker/Börsianer Die CPUs sind irgendwelche Eigenbrütler die mit Power im gleichen Kindergarten waren. Mehr nicht.

PowerPCs sind die Schulkinder der Power-Architektur, die damals aus verschiedenen gründen sinnvoll waren/erschienen.

"Power" laufen in "p" und "e".

Die interessantesten Competitors kommen von Fujitsu/Oracle (ehem. Sun). Dem Power möchte der SPARC64 einheitzen, den z-Units der SPARC T.
Wobei mir der T4 kleinwenig versemmelt erscheint, mit seinen 240 Watt. Der T3, wenn man den mal als Datenschleuder erleben kann, rennt mit 2-4 CPUs absolut beeindruckend.
Ein SPARC64 IXfx knallt 2 GFLOPS pro Watt und begnügt sich dabei mit 115W. Auch nicht von schlechten Eltern.

Beide Sparcs adressieren aber imho eher den fast High-End Markt. Gegen "p" kommt man (und auch andere) noch brauchbar an. Die "z" hat eher keine Gegner.
Wobei sie aber auch extrem spezifisch ist. Für den Aufwand den man da treiben müßte um gegen die anzustinken resultiert am Ende in einem zu kleinen Kuchen den man sich teilen müßte. Man läßt IBM dadrin ohne größeren Neid rumplanschen.

Was IBM PR-technisch selbstverständlich wohl anders sieht ABEr, hier geht es nicht um "z". Da läuft kein Power7

Ciao.

 

[geislpxs]

@[F]L4SH
Du hast das erste Smartphone mit Touchscreen vergessen zu erwähnen (15Jahre vorm Iphone).

 

[calluna]

@Flash

Wird nicht ein X86 Prozessor, der eigentlich als RISC beworben wird zum CISC, weil man diesen ganzen unvorstellbar "nutzlosen" Ballast wie 8 und 16 bit, altes SSE und was weiß ich mitschleppt?

Der Ballast ist vernachlässigbar. Selbst bei den XeonPhi mit mehr als 50 Kernen und 4fach HT ist ja kein Problem.
Und SSEx ist derzeit definitiv kein Ballast und wird ohnehin über die AVX Register ausgeführt. AVX 1 & 2 kann man zudem als einen schleichenden "Cut" betrachten.