Re: bytegroesse, was endianess/Re: audio-cd

From: Bernd Walter <ticso(at)cicely8.cicely.de>
Date: Wed, 27 Mar 2002 00:28:38 +0100

On Tue, Mar 26, 2002 at 10:38:15PM +0100, Michael Haertl wrote:
> Bernd Walter wrote:
> > Michael Haertl wrote:
> > > Der Pfad L1-Cache<-->Register ist nicht wirklich langsam. Und
> > > weniger benoetigte Befehle sind meistens schneller als mehrere.
> >
> > Registeroperatioenen können richtig verschachtelt in der Pipeline
> > nebenher laufen, weil diese durch die verschachtelung Abhängigkeit-
> > enkoppelt sind.
>
> Deswegen sind weniger benoetigte Befehle i.d.R. doch immer noch
> weniger Aufwand und Ausfuehrungszeit. Die "frei" gewordene Pipeline
> koennte man ja auch fuer andere Befehle nutzen.
>
> Ganz geht mir das noch nicht ein. Es ist wohl so.

Es sind halt einfach nicht weniger Befehle - nur weniger Opcodes.
Der Punkt ist halt nur, daß es im Hintergrund ungesehen passiert.
Die Pipeline macht immer noch was vergleichbares - nur mit weniger
Tips vom Compiler - dafür mit kleinerem Code und mehr Hardware.

> > > Vielleicht denke ich zu sehr auf Bitebene in DSP-Systemen und
> > > zu wenig in "-O3" (obwohl _mir_ das oft vorgeworfen wurde).
> >
> > Auf moderne DSPs können durch eine richtige Reihenfolge derartige
> > Befehle ohne nennenswerten Zeitverlust gleichzeitig behandeln.
>
> Meiner Meinung nach machst du es dir hier zu einfach. Die Pipelines
> bei den DSPs sind bei weitem einfacher aufgebaut als bei einem
> der verbreiteten Desktop-Prozessoren. Und die moegliche parallele
> Befehlsabarbeitung ist i.d.R. auf wenige sehr spezielle Anweisungen
> beschraenkt (das dafuer halt extrem optimiert).

DSPs hinken der Entwicklung immer etwas hinterher, da der Markt nicht
so sehr der neuesten Version hinterherhechelt.
Da lassen sich embedded AD/DA Wandler und lange Produktionszeiträume
besser verkaufen.
Das Pipelines einfacher aufgebaut sind liegt aber im wesentlichen
daran, das die eben keinen komplexen Befehlsballast mitschleppen.
Letzendlich gibt es aber die gleichen Effekte - nur ein paar Jahre
später.

> Tatsache ist, dass man typische fuenferl-Variablen auf einem
> DSP oft in Silizium behandelt (z.B. Schleifenzaehler, Adressoffsets),
> es ist (zumindest im Falle DSPs) einfach effektiver und schneller.

Schleifen haben auf DSPs auch eine ganz andere Häufgikeit als bei
Desktop oder Serverprozessoren - da kann man besser andere Befehle
weglassen.
Dadurch, das klassische DSP Aufgaben immer stärker auf Desktopmaschinen
drücken, wie mp3 & Co versucht man das dann mit Multimedia
Erweiterungen wieder wettzumachen - eine DSP wird mit diskreteren
aber besser Selektierten Befehlen immer noch darüber schmunzeln.

> > > > Außerdem landen die eh in einem Register, was die Maskierung
> > > > nach dem laden überflüssig macht.
> > >
> > > Die Anzahl der Register ist ja auch nicht unendlich. Man muss
> > > ja schliesslich auch noch was arbeiten.
> >
> > Eine Alpha hat 30 Integer und 30 Floatingpointregister.
> > Wenn du es dann noch schaffst einen Schleifenzähler nicht mehr mit
> > einem Register abgedeckt zu bekommen hast du ein anderes Problem.
>
> Zugegeben, 30+30 ist schon ganz angenehm. Aber es gibt nicht ueberall
> soviel und nicht immer kann man dann alle benutzen.

Immer wenn ich einen Befehl weglasse muss ich überlegen wie ich den
Verlust wettmache.
Einerseits schaffe ich mir dadurch Siliziumfläche für Register und
zum anderen kann ich durch eine einfachere Pipeline Takzyklen sparen.
Das Ergebniss kann also durchaus besser sein.

> > Warum etwas mit Hardwareaufwand und zulasten der restliche Performance
> > implementieren, was sich mit wenigem Aufwand vermeiden lässt?
>
> Frage zurueck: warum haben das wohl die bereits angesprochenen DSPs
> oft in Hardware implementiert (ohne zu Lasten der restlichen
> Performance) ? Es geht einfach schneller. Trotz weniger MHz. Und
> spart den Luefter ;-)

Hardware ist schneller als Software, solange die Nutzungshäufigkeit
die gesteigerte Hardwarekomplexität gerechtfertigt.
Man kann auch ganze Systemlibs in Hardware gießen und das Ergebniss
wird miserabel sein - es geht halt immer um das Mass der Dinge.
Man optimiert für das was gebraucht wird - und auf misaligned Zugriffe
kann man ebenso verzichten, wie eine Alpha auf 8/16 bit loads.
Wenn ich will das schlecht programmierter Code immer noch schnell ist
lande ich in der x86 Falle.

> > Nein - auch ein x86 hohlt sich mehr als nur ein Byte rein und muss
> > das isolieren - das passiert indem der »Einzelbefehl« in entsprechende
> > Microcodes aufgelöst wird.
>
> Ich kenne die Microcodes nicht im Detail ;-) Aber ich wuerde da nur ein
> Tor umschalten, damit waere das eigentlich noch ohne Overhead im "Move"
> realisierbar.

So einfach ist es bei heutigen CPUs nicht.
In der Regel sind es getrennte Pipelineschritte die aufeinander
warten müssen, weil einer auf das Ergebniss des anderen wartet.

> > Allerdings hat ein x86 das Nachsehen, weil die Reihenfolgenentkoppelung
> > zur Laufzeit bewerkstelligt werden muss und nicht mehr zur Compilezeit.
>
> Ein x86 ist ein gutes Beispiel fuer nicht ganz so viel verfuegbare
> General-Purpose-Register. Wenn ich mir das Stack-Geschubse bei einem
> Unterprogrammaufruf so ansehe, dann frage ich mich manchmal, wann da
> die eigentliche Arbeit erledigt wird.

Ich habe auf einem C64 in Assembler programmiert und selbstgebaute
m68k Boards programmiert.
Zu meinem ersten x86 habe ich mir dann natürlich aus Gewohnheit gleich
ein Assemblerbuch gekauft und es direkt in die Ecke gestellt.
Ich konnte es nicht begreifen, das man einen x86 wesentlich schwieriger
in Assembler programmieren konnte als einen m68k in Maschinensprache.

-- 
B.Walter              COSMO-Project         http://www.cosmo-project.de
ticso(at)cicely.de         Usergroup           info(at)cosmo-project.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Wed 27 Mar 2002 - 00:30:30 CET

search this site