OT: Sparc vs. x86

[Jan-Benedict Glaw]

On Sun, 2003-06-01 21:08:16 +0200, Thomas Findeisen <npl at npl.de>
wrote in message <3EDA4F20.E2F866A5 at linuxbu.de>:
> > Der Befehl als solches braucht bei korrekter RISC implementierung nur
> > einen Cycle
> 
> Ist oft so, aber allgemein falsch.

Ja? Davon ausgehend, daß es keine Probleme in der/den Pipelines gibt,
war ich davon ausgegangen, daß die meisten Befehle wirklich nur eine CPU
cycle brauchen. Allerdings kann's sein, daß man mit dem nächsten Befehl
noch nicht inbedingt auf das Ergebnis des verherigen zugreifen darf...

> > - 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.

Das ist bei allen neueren Intel-CPUs so. Man schleppt da den ganzen
CISC-Overhead mit (sprich: die Dekodier-Logik, um daraus gemäß des
(übrigens teilweise änderbaren) Microcode der CPU wieder RISC-Befehle zu
machen. Na prima. Das könnte man im Compiler mindestend genauso dolle
erledigen.

> > 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.

Das mit der Performance ist immer so eine Sache. Gerade die Alpha ist da
immer recht streitbar, da bei ihr ja u.U. das Betriebbsystem bei
Fließkomma-Rechnungen noch nachhelfen muß. Solange Du "passende" Zahlen
an eine Alpha verfütterst, ist sie schnell. Sehr schnell. Aber laß' ihr
bloß nicht in großem Umfang nicht-normalisierte IEEE-Fließkommazahlen
über den Weg laufen...

> > 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 ;)

ACK:) Slowlaris, wie man es kennt:)

> > - 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,..)

Jo. Bauen die Intel-Kompatiblen eigentlich mittlerweile CPUs mit 8MB
Cache?

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw at lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
      ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lug-owl.de/pipermail/linux/attachments/20030601/d7891876/attachment.sig>