4. Füllbytes - Wieso?

Füllbytes - Wieso?

  • H

    Hi,

    ich hab hier irgendwo gelesen, dass manche Compiler Variablengrößen auf Vielfache von 2 (oder warens 4?) im Speicher bringen (sogar bool), weil es irgendwie Performance bringt oder so. Was ist denn der Grund dazu und wie kann man sich das erklären?

    MfG, Herr-Vorragend

    0
  • ?

    Weil der Prozessor immer 4 bytes einliest.

    0
  • Z

    wort schrieb:

    Weil der Prozessor immer 4 bytes einliest.

    wohl eher weil bei x86 prozessoren das lesen von speicherinhalten in register für offsets an 4-byte grenzen optimiert ist.
    Kurt

    0
  • H

    ZuK schrieb:

    wort schrieb:

    Weil der Prozessor immer 4 bytes einliest.

    wohl eher weil bei x86 prozessoren das lesen von speicherinhalten in register für offsets an 4-byte grenzen optimiert ist.
    Kurt

    ja und wieso ist er darauf optimiert? Oder wie ist das ganze implementiert?

    0
  • Z

    Über die interna der x86 prozessoren kann ich dir nicht viel sagen. Möglich ist natürlich auch wie wort schon sagte dass der prozessor eigentlich immer 4-byte einliest und und wenn du zb ein 2 byte datum anforderst das über eine solche 4-byte grenze geht der prozessor dann eben 2 speicherzugriffe benötigt.
    Kurt.

    0
  • D

    Der Zugriff auf Speicheradressen ist auch schneller, wenn die Adresse durch 4 Teilbar ist. Wie das genau zustande kommt hab ich irgendwie vergesst.. 😞
    Naja, es gibt auch Rechner bei denen werden für viele Datentypen explizit 4er-Grenzen oder 2er-Grenzen als Ablageort vorgeschrieben.
    Ein Beispiel ist die S140er Großrechner-Serie und alle Nachfolger bis zur neuen S190..

    0
  • P

    Da die Registerbreite bei den x86 Prozessoren 32 Bit ist, ist der Zugriff auf Adressen die durch 4 teilbar sind wesentlich günstiger, da das memoryInterface nur an einer durch 4 teilbaren Adresse anfangen kann zu lesen.
    Hab ich z.B meine variablen gepacked (oder compressed angelegt)

    typedef struct {
char a;
char b;
char c;
int IntValue;
} TestSTRUCT;

TestStruct tesr;

    Muß der Processor für test.IntValue erst das 32 Bit wort lesen das bei char a beginnt, sich davon das letzte Byte merken dann das nächste Wort lesen 8 Bit nach links shiften und dann das einzelne Byte hinzufügen.
    Bei dem Konstruct

    typedef struct{
int IntValue;
char a;
...
} TestSTRUCT;

TestStruct tesr;

    liest er test.IntValue in einem Zugriff. Diese Aktion ist complett unabhängig von der Stelle an der die Daten stehen (First/Second level Cache, RAM);

    Die DefaultEinstellung bei MSVC ist sogar eine Alignment auf 8 Byte, dies hat dann meistens etwas mit den cache lines (länge 64/128 Bit) oder dem Ram Memeory Access zu tun

    Allerdings bieten die meisten Compiler nicht im Standard definierten Compilerdirektiven an,mit denen man das Alignment deaktivieren kann.

    Übrigens nicht nur die PC Welt davon betroffen sondern auch viele andere Prozessoren, bei manchen ist es sogar unzulässig nicht alignete Daten zu verwenden.

    Dieses Alignment erschwert die Zusammenarbeit mit unterschiedlichen Compilerern, wenn man nicht darauf achtet das alle das gleiche Alignment nutzen.

    Ich hoffe, das in Windows das Alignment überall 8 Byte ist, da es als default bei MS eingestellt ist.

    Interessanterweise hatten wir schon Schwierigkeiten MS VB und VC mit derselben dll zusammenarbeiten zu lassen, da VC Alignment 8 byte und VB scheinbar 1 Byte hatte. Als wir verschsweise VC auf Alignment 1 umstellten ging es.

    0
Anmelden zum Antworten