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

From: Bernd Walter <ticso(at)cicely8.cicely.de>
Date: Tue, 26 Mar 2002 17:21:52 +0100

On Tue, Mar 26, 2002 at 04:18:14PM +0100, Michael Haertl wrote:
> Bernd Walter wrote:
> > Michael Haertl wrote:
> > > Oliver Fromme wrote:
> > > > Michael Haertl wrote:
> > > > > Oliver Fromme wrote:
> > > > > > [...]
> > > > > > lesen. Wenn ein Programm nur ein Byte braucht, muß es
> > > > > > durch Maskierungs- und/oder Verschiebeoperationen heraus-
> > > > > > gefiltert werden.
> > >
> > > Wenn das in Software passiert, dann klingt das nach uferlos
> > > Overhead.
> >
> > Absolut nicht.
> > Ein Speicherzugriff dauert lange und die paar Registerzugriffe
> > für die Maskierung kann in der Regel gleichzeitig zum nächsten
> > Befehl passieren.
>
> 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.

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

> > > > > ["Verschwendung", d.h. z.B. sizeof(char) == sizeof(long)]
> > > > > Fuer den Standardfall (z.B. logische Variablen,
> > > > > "kleine" Schleifenzaehler) ist dann eigentlich kein Workaround
> > > > > notwendig.
> > > >
> > > > Verstehe ich nicht, wozu ein Workaround?
> > >
> > > Ja eben das Shiften/Maskieren beim extrahieren von Octetts aus
> > > einem "Word" meinte ich.
> >
> > Schleifenzähler macht man mit einem int.
>
> Sagt auch keiner was anderes. Aber ist int auf einer Alpha
> 64 bit ? Oder muss ein 32bit-int nicht auch aus einem 64bit-
> (128bit?)Wort extrahiert werden ?

Ein int ist 32bit.
Die Register sind alle 64 bit - es gibt Ladebefehle als 32 und
64 bit - bei aktuellen CPUs als Zugeständniss an schlechte Compiler
auch als 16 und 8 bit.

> > 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.
Es ist recht typisch, das RISC CPUs mit vielen Registern daherkommen.
Im CISC Bereich kann wohl die m68k Familie als Ausnahme gelten, aber
auch die sehen misaligned Zugriffe überhaupt nicht gerne.
Warum etwas mit Hardwareaufwand und zulasten der restliche Performance
implementieren, was sich mit wenigem Aufwand vermeiden lässt?

> > > in ein Speicherwort zu packen. Das Extrahieren eines chars
> > > aus diesem Wort kostet Codesize und Performance [...]
> >
> > Performance eben nicht. Gemacht werden muss das ja sowieso.
>
> Gemacht werden muss das eben nicht sowieso. Man kann einen
> "kurzen" Datentyp ja auch in einem Wort (nativer Prozessorbreite)
> unterbringen und benoetigt dann eben nur einen Ladebefehl und
> nicht einen Ladebefehl + Lade_Maske + Maskierbefehl.

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.
Allerdings hat ein x86 das Nachsehen, weil die Reihenfolgenentkoppelung
zur Laufzeit bewerkstelligt werden muss und nicht mehr zur Compilezeit.

> Natuerlich ist das nicht unbedingt auf alle Situationen anwendbar.
>
>
> > [Byte-Befehl auf Alpha]
> > Mit dem Compaq Compiler haben die Befehle fast keinen Unterschied
> > gemacht.
>
> Von welchem "Compaq Compiler" sprichst du (sprich: fuer welches
> OS) ?

/usr/ports/lang/compac-cc.
Der ist zwar ein Linuxcompiler, erzeugt aber aufgrund des Ports native
FreeBSD Code.
Für die Tru64 Version gilt aber gleiches.
Das Problem ist, das dem gcc die geschickte Plazierung der Befehle
nicht so gut gelingt.

> > [non-aligned Buszugriffe]
> > Deshalb sollte auch auf x86 Maschinen richtig programmiert werden.
> > Aber das verstehen die meisten nicht.
>
> Es ist halt oft auch nicht wirklich relevant. Megaherze sind ja
> meist genuegend da. Und auf Hochsprachenebene moechte man
> sich darum auch gar nicht so sehr kuemmern (dafuer gibts
> schliesslich compiler), da sind andere Dinge dann wichtiger.

Eine stagnierte Pipeline macht viele Megaherzen kaput.
Auf jeder Pipeline CPU - selbst auf einer Hardwired 6502.
Ein Compiler kann auch nur das umsetzen was verlangt wird.
Natürlich optimiert man nur oft benutzte Routinen, aber es gibt
halt einige Grundregeln die zum anständigen Programmieren dazugehören.
Und das ist mehr als nur Variablen initialisieren, was ja auch
erschreckend lange gutgeht.
Die Reihe lässt sich mit Unverständniss über nicht koheränte
Speichermodelle bis hin zu den exotisch großen default pthreadstacks
bei Linux weiterführen.

-- 
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 Tue 26 Mar 2002 - 17:30:39 CET

search this site