OT: Sparc vs. x86

[Thomas Findeisen]

> Der Befehl als solches braucht bei korrekter RISC implementierung nur
> einen Cycle

Ist oft so, aber allgemein falsch.

> - Leider bewirkt er auch nur so viel wie halt die CPU bei
> gegebener komplexitaet bewerkstelingen kann. D.h. obwohl eine CISC
> instruktion mehr cycles braucht bewirkt sie mehr.

Nein. Denn gerade beim P4 wird aus dem CISC-Microcode am Ende eh nur
wieder Risc draus. Der Gewinn bleibt dem Programmierer, er hat eine
mächtige Code-Bibiothek. Mehr nicht.

> Unterm strich kommt meistens aehnliche Performance bei raus. Nur leider
> verbrauchen die CISCs mehr strom.

Nein, die Performance ist deutlich höher, beim Alpha ca. 5 mal so hoch
wie beim P4, bei gleicher Taktfrequenz. Bei der Sparc noch mehr als 4
mal.

> Und das die SPARCs bei multithreading besser abschneiden halte ich fuer
> ein geruecht. Das hat wiederum nichts mit der CPU sondern dem
> Betriebssystem zu tun. Und was syscall zeiten angeht ist die SPARC nicht
> gerade beruehmt und NPTL ist spaetestens der Bart ab.

Ok, aber straf die CPU nicht für ihr OS ab. Was die Software am ende
draus macht is was anderes ;)

> RISC ist nur schneller wenn ich die cycles einzelner instruktions
> vergleiche

Flsach.

> - Und das ist wie man sicher erahnen kann weltfremd. Es geht
> um real world workload.

Bislang ging es um Risc/Cisc. Wenn es um 'real world workload' geht,
sollten wir mehr als nur die CPU beachten. (L1,L2,RAM,Bus,..)

MfG Thomas Findeisen
-- 
Da hat mal auf ner Party jemand ne Kippe auf meiner Floppy
ausgedrueckt... toeten kann so befriedigend sein
[Countzero, www.dienstagstreff.de]