29. November 2012 03:11

Re: 64 Bit sind weitgehend nutzlos

Hede schrieb am 27. November 2012 13:00

> > zweitens arbeitet Dein Rechner öfter als Du denkst mit Werten > 4
> > Milliarden. Ein Filepointer beispielsweise ist 64-Bit gross. 

> Der kommt zum Einsatz, wenn man auf ein Medium mit Transferraten von
> unter 1GB/s zugreift. Ich wüsste jetzt nicht, wie hierbei der
> Flaschenhals überhaupt innerhalb der CPU entstehen sollte.

häh? Ein Filepointer hat rein GAR NICHTS mit der Geschwindigkeit zu
tun. Damit addressierst Du Positionen innerhalb einer Datei beim
Lesen/Schreiben. Mit einem 32-Bit Filepointer könntest Du also nur
ca. 4GB grosse Dateien anfassen. Daher ist der Filepointer 64-Bit
gross, damit Du auch gössere Dateien bearbeiten kannst. Und das ist
auch auf 32-Bit Systemen so!

> Der rechnet bei AMD64 zwei 32 Bit Ints mit einem 64 Bit-Register?

wäre denkbar, der GCC kann sowas. Also ähnlich skalar wie mit SSE,
wobei das meist nur bei ORs und ANDs und auch Wertezuweisungen
passiert. Gesehen habe ich dieses Verhalten zumindest beim GCC schon.
Musst den Autovektorisierer einschalten, dann macht der sowas.

> Interessant. Die normalen Integer-Einheiten des AMD64 haben splittet
> carry over? Wusste ich noch gar nicht. Irgendwie muss man dann ja
> feststellen, ob ein Overflow im Low Double-Word stattgefunden hat.

Ich sagte VERARBEITEN, nicht RECHNEN. Kleiner aber feiner
Unterschied.

Sowas wie:

   int i;
   short *a, *b, *c;
   c[i] = a[i] | b[i];

kann man problemlos bei einer Schleife auch skalar in einem 64-Bit
Register 4 x parallel ausführen. Und ja, der GCC kann sowas!

> Sonst hat man am Ende gleich zwei falsche 32 Bit-Werte. Und so
> einfach ist das ja auch nur bei der Addition, wie macht man das
> überhaupt bei der Multiplikation? Da hab ich wohl eine Wissenslücke.

Ich habe niemals von Addition und Multiplikation geredet. Aber da
hast Du wohl in die falsche Richtung gedacht. ;-) 

> Nope. Ein bisschen was, aber so viel ists nicht. Wenn man noch in den
> 80ern stecken würde und es wirklich Speicherzugriffe erfordern würde,
> ja. Aber Heute, mit modernen Out-of-Order-CPUs, stecken die passenden
> Werte doch eh meist schon in irgendwelchen Buffern oder Caches (also
> noch näher an der CPU als im L1-Cache). 

Ein Wert der in RAM geschrieben werden muss, *muss* da auch abgelegt
werden. Da hilft Dir Dein L1-Cache nur bedingt. Gelesen kann daraus
schneller werden, ja. Aber jeder Schreibzugriff muss auch durch die
Caches hindurch aufs langsame RAM erfolgen. Das ist bei einem
Register nicht der Fall.

> > *DATEN* sind es nicht zwangsläufig. Ein uint32_t ist immer
> > 32-Bit gross. Egal auf welcher Plattform.

> Ja, das stimmt. uint32_t, aber wer nutzt das so direkt?

*ICH* und jeder andere Programmierer, der nicht erst seit gestern
programmiert auch. Die ganzen (u)int(8/16/32/64)_t Typen gehören
schon seit vielen Jahren zum C-Standard dazu. Das ist schlicht bei
jedem modernen C-Compiler vorhanden. Nur manche Programmierer haben
das noch nicht geschnallt.

#include <stdint.h>

> Schon int ist es nicht generell! Und das wird wohl häufiger einfach
> benutzt.

int32_t ist ein signed integer, uint32_t ist ein unsigned integer.
Die Bitbreite gibt die im Namen enthaltene Zahl an. Zudem gibts auch
noch ofs_t und size_t für Pointer-Indices und sowas wie int_fast32_t
und int_least32_t.

Nochmals, wenn man für den entsprechenden Einsatzzweck den richtigen
Datentyp wählt, hat man keine Probleme. Und wer bei "int" Annahmen
über die Grösse macht, der macht grundsätzlich was falsch. Unter DOS
ist ein int nur 16-Bit gross!

Ja, ich benutze auch ab und an "int", aber nur dann wenn es sich um
kleine Scheifen handelt, bei denen ich weiss dass ich selbst 16-Bit
niemals überschreiten werde. Ansonsten benutze ich einen der anderen
Typen. Insb. bei Speicherzugriffen sollte man size_t benutzen.

afaik.

Anzeige

heise online Themen