ARCHIV 1999-2006

ARCHIV :: # 2170

x86 vs PPC: Eine Bestandsaufnahme und Analyse

My big Indian is better than your little Indian!...

Autor: kai - Datum: 10.07.2003

Auch auf MacNews gefunden: Eine zwar sehr lange aber auch sehr interessante Abhandlung auf OSnews.com über RISC vs CISC, PPC vs x86 im Allgemeinen, G5 Benchmarks im Speziellen und einem interessanten Ausblick auf die Zukunft.
In jedem Falle gutes Grundlagenwissen, nicht so extrem harte Kost wie ArsTechnica aber trotzdem nicht oberflächlich! ;-)

Kommentare

Mein Statement dazu...

Von: 68k_mac | Datum: 10.07.2003 | #1
no RISC, no FUN!

Bedingt durch meinen laienmässigen Verstand was Chipdesign angeht, kann ich mir kein fundiertes Urteil bilden, welche Architektur DIE bessere ist.

Das was ich aber im Laufe der Jahre so gelesen habe, lässt mich zu dem Schluss kommen, dass die RISC Architektur die elegantere ist.

Ausserdem kommt bei mir immer so etwas wie Workstation feeling auf, wenn ich an meinem Mac OS X - UNIX - RISC Mac sitze :-)
Fast wie ein kleiner Supercomputer ;-)

CISC war für mich nie ein Thema. Das könnte aber auch daran liegen, dass CISC Prozessoren meist mit dümmlich programmierten und schlecht zu bedienenden Redmonder Betriebssystemen gequält werden.

Gruss, 68k_mac

Das auch interessant...

Von: Tobsen | Datum: 10.07.2003 | #2
Kleiner Artikel mit Link zu deren Forum mit einer Spekulation, wie schnell der G5 in Audio sein wird.
[Link]

aktuelle iX mit interessantem Vergleich..

Von: TheBurgerKing | Datum: 10.07.2003 | #3
..der Benchmark Odyssee auf Seite 1

lesenswert (wie immer) !

Einer der Besten

Von: conjoint | Datum: 11.07.2003 | #4
Leser conjoint schrieb am 11.07.2003:

Dieser Artikel ist sachlich, ausführlich und verständlich geschrieben. Ein sehr schönes Werk, was sich zu lesen lohnt.

Für das generelle Verständnist eignet sich der Artikel, als auch zur normalen Argumentation, denn eine Argumentation mit ArsTechnica Artikeln kann dann schon etwas schwierig werden, wenn zumindest einer der beiden Argumentatoren nicht wirklich Ahnung von dem Prozessorthema hat.

Also seit langem mal wieder ein schöner Artikel.

Leserbewertung: *****

@ TheBurgerKing

Von: at | Datum: 11.07.2003 | #5
Inzwischen ist die iX das, was vor einiger Zeit die c't war, während deren Niveau kontinuierlich abfällt. Kurz:
iX = c't - 10 Jahre
c't = chip - 10 Jahre
Und zu RISC vs. CISC:
Was angesichts immerhin allein 162 Vectorbefehlen das R in RISC zu suchen hat, ist mir ein Rätsel. Nicht nur, dass es für eine solche Bezeichnung schlicht zu viele Befehle sind, sondern "reduced" stimmt spätestens seit dem Sprung von G3 auf G4 nicht mehr, da sich die Anzahl der Befehle spürbar erhöht statt verringert hat.

at:

Von: Kai (MacGuardians) | Datum: 11.07.2003 | #6
Bitte lies den Artikel, da wird genau darauf eingegangen! ;-)

Der Punkt ist, dass x86 intern RISC-like sein mag, aber es braucht immer noch den Befehlsdecoder und dass massive Register-Renaming für die simpelsten Dinge, was bei RISC einfach nicht nötig ist!
Weiterhin ist der Code den das Ding frisst eben immer noch x86-CISC-Code, da beisst die Maus keinen Faden ab!

Ich sag ja auch nicht, dass ich spanisch spreche, nur weil ich Zugang zu einem Übersetzer (Babelfish) hab! ;-)

Intel & CISC

Von: Leo | Datum: 11.07.2003 | #7
Was mich immer noch wundert, ist, warum Intels CISC- (oder Pseudo-RISC)-Designs so schnell sind. Die Altlasten, die die x86-Architektur mit sich rumschleppen muss, sind immens. Mich beeindruckt das jedenfalls.
Den Performancevorteil, den die PowerPC-Architektur aus ihrem eleganteren Ansatz herausholen können sollte, ist geringer, als ich es mir wünschen würde.

@Kai: Auch eine RISC-CPU wie PowerPC hat einen Befehlsdecoder (wie jede Von-Neumann-ähnliche Architektur)

@ Kai

Von: at | Datum: 11.07.2003 | #8
Nur damit wir uns nicht missverstehen:
Ich meinte nicht die x86-Schiene, sondern den PPC.

@at: RISC & reduced instruction set

Von: Leo | Datum: 11.07.2003 | #9
RISC und CISC werden nicht (mehr) anhand der Zahl der Befehle, sondern an der Art der Befehle unterschieden.
Der 68000er (CISC) hat nur 56 Befehle, jedoch 2-10 Byte lang. Beim PowerPC sind alle Befehle genau 32 Bit lang, ein eindeutiges Zeichen für RISC. Beim Pentium sind die Befehle zwischen 1 und 12 Bytes lang (die ersten Bytes beinhalten Opcode, Mode und Register-Fields) was eindeutig für CISC spricht.

[Link]

Befehlsdekoder im G3/G4

Von: Leo | Datum: 11.07.2003 | #10
Doch, auch der G3 und der G4 haben einen Befehlsdecoder. Er ist jedoch ein reiner, einfacher Hardware-Decoder, während der Microcode-Decoder in den x86-Designs erheblich komplizierter ist.

Hannibal von Ars Technica hat (wie immer ;-) ) ein paar erleuchtende Worte dazu zu sagen...

[Link]

Leo:

Von: Kai (MacGuardians) | Datum: 11.07.2003 | #11
Okay, ist klar, fest verdrahtet ist aber IMHO was anderes! ;-)
Es geht um die CISC->RISC Translation, die beim G3/G4 nun mal so einfach nicht stattfindet!
Der G3/G4 arbeitet AFAIK nicht mit Microcode (wobei mich da das hier schon verwirrt hat:"Avoid microcode" - oder meinen die damit nur den G5?), insofern ist das nicht vergleichbar mit den x86-CPUs und ihren RISC-ops!

Das witzige ist, dass die Leute immer denken, dass CISC gewonnen hat, aber da alle CISC intern eigentlich RISC sind und sie die wichtigsten Konzepte davon übernommen haben (OOO-Execution, Pipelining) hat sich die Überlegenheit von RISC ganz klar bewiesen und RISC hat eigentlich gewonnen!

Hannibal bestätigt das ja:

Von: Kai (MacGuardians) | Datum: 11.07.2003 | #12
"The K7's decoding scheme is much more complicated than the 7400's, because the K7 has to deal with the vagaries of the aging and oft-maligned x86 ISA. The K7 pays a steep price, in terms of transistor resources and clock cycles, for x86 compatibility. First off, AMD added a predecode cache to help deal with the variable lengths of the x86 instructions; this is extra cache space that the G4 doesn't need. Furthermore, the K7 doesn't run the big, unwieldy x86 instructions directly, but it decodes them into what AMD calls MacroOps. Each MacroOp is composed of one or two smaller instructions: a register-to-register instruction and a memory access instruction (LOAD, STORE, or LOAD/STORE). These smaller instructions are just called ops, and a single one of them is roughly equivalent to a P6 "rop", or to one of the 7400's ordinary instructions. In this way, the K7 emulates the x86 ISA using RISC-like instructions that correspond to regular instructions on a RISC machine."

@Kai: G5 und Microcode

Von: Leo | Datum: 11.07.2003 | #13
Du hast schon richtig gelesen bei developer.apple.com.
Der G5 führt die Zerlegung in MicroOps bei einigen Befehlen wieder ein.

Leo:

Von: Kai (MacGuardians) | Datum: 11.07.2003 | #14
Ja, das ist mir schon klar, aber was ich wissen will ist, ob das bei G3/G4 auch schon so war! ;-)
Das Dokument sagt den Leuten ja, was sie beachten müssen bei G5-Programmierung, und wenn ich das mit den anderen Dos und Don'ts vergleiche könnte man auf die Idee kommen, dass Microcode beim G3/G4 beliebt war, und man's jetzt eben vermeiden sollte!

Wenn nein, was meinst du dann mit "wieder einführen"? ;-)

@Kai: Klärung

Von: Leo | Datum: 11.07.2003 | #15
Es ist so:

- G3/G4 zerlegten keinen Befehl in Microcode. Nur der G5 tut das.

- Nicht der "Microcode war auf dem G3/G4 beliebt", sondern das für G3/G4 von den Compilern erzeugte Kompilat enthielt u.U. Assemblerbefehle, die im G5 (jedoch nicht im G3/G4) in Microcode zerlegt werden müssten (jedoch aus Kompatibilitätsgründen verarbeitet werden können) und eine Pipeline-Bubble verursachten.
Diese Befehle sind von IBM durch neue, ähnliche Befehle ersetzt worden. Apple legt nahe, wenn möglich die neuen Befehle zu verwenden.

Pipelines sollten nämlich stets gerammelt voll sein. ;-)

Nachtrag

Von: Leo | Datum: 11.07.2003 | #16
Die Vermeidung der "alten" Befehle geschieht durch eine Compiler-Einstellung.

SIMD ist ein alter Hut

Von: tjp | Datum: 11.07.2003 | #17
Es gibt Vektorprozessoren schon lange, was neu ist ist die Kastraten Implemetierung. AltiVec kann nur mit 32Bit Floats rechnen (4x32Bit=128Bit, halbe Genauigkeit der FPU, die rechnet wahlweise mit 32Bit oder 64Bit Floats) während ältere Vektorprozessoren wie die Rechner von NEC, Fujitsu, Cray mit 64Bit Floats rechnen können.

Der Unterschied liegt im Anwendungsbereich, während ein Vektorprozessor für SciTech Anwendungen benutzt wird/wurde taugt SIMD ala AltiVec nur für Multimedia.

@tjp

Von: Leo | Datum: 11.07.2003 | #18
"...taugt SIMD ala AltiVec nur für Multimedia."

Na, jetzt übertreibst du. Es gibt viele Leute, die die Altivec-Einheit massiv in der Forschung einsetzen, vor allem im universitären Umfeld (ich zum Beispiel ;-)). Nicht jedes numerische Problem verlangt doppelte Gleitkommagenauigkeit.
Der G4 ist z.B. in FFTs dank Altivec rasend schnell (gegenüber den Pentiums geradezu konkurrenzfähig ;-)). Die Altivec-Einheit hilft sogar bei schnellen Implementierungen für Oct-Precision-Arithmetik (265-Bit-Floats).

Schau mal hier rein:
[Link]

Stimmt..

Von: Kai (MacGuardians) | Datum: 12.07.2003 | #19
Ich erinnere an das NASA-Jet3D oder an das Altivec-optimierte BLAST oder auch Crypto-Sachen wie RC5.

Aber kann mir jemand ne Frage beantworten? Es hiess doch immer, dass Altivec entweder mit 8x16bit, 4x32bit, 2x64bit oder einer 128bit-Zahl rechnen kann! Dies schrieb jedenfalls damals Andreas Stiller in seinem SIMD-Vergleich.
Also warum nimmt man dann nicht die 2x64bit und rechnet damit DP?

Indian???

Von: housemaister | Datum: 12.07.2003 | #20
Was bitte schön ist big bzw. little Indian?
Ein Schreibfehler oder ein Denkfehler?

Altivec-Register & Little-/Big-Endian

Von: Leo | Datum: 12.07.2003 | #21
Altivec kann:
16x8bit Ganzzahl
8x16bit Ganzzahl
4x32bit Ganzzahl
4x32bit Gleitkomma
Sonst nix, insbesondere kein 2x64 oder 1x128, denn dann wäre die Altivec-Einheit zu komplex (sie kostet uns jetzt schon kräftig MHz). Viele Profis würden sich aber eine 4x64bit-Einheit wünschen, da hätten aber nur wenige Nutzer was von.

Zur "Endianity": [Link]

housemaister:

Von: Kai (MacGuardians) | Datum: 12.07.2003 | #22
Man nennt es "Scherz", aber es geht im Internet leider fast grundsätzlich schief! ;-)

Leo: Danke für die Info!