Strukturen vergleichen



  • SeppJ schrieb:

    Autowech schrieb:

    Konnte man nicht das Padding ausschalten und/oder per Hand erledigen? Automatismen sind ja nicht immer wünschenswert.

    Könnte man, aber wieso sollte man das wollen? Bloß um beim Vergleich faul sein zu dürfen? Das Padding ist ja nicht bloß da, um den Programmierer zu ärgern.

    Umsonst wird man kaum eine Option in den Compiler eingebaut haben um das Padding zu deaktivieren.


  • Mod

    Autowech schrieb:

    SeppJ schrieb:

    Autowech schrieb:

    Konnte man nicht das Padding ausschalten und/oder per Hand erledigen? Automatismen sind ja nicht immer wünschenswert.

    Könnte man, aber wieso sollte man das wollen? Bloß um beim Vergleich faul sein zu dürfen? Das Padding ist ja nicht bloß da, um den Programmierer zu ärgern.

    Umsonst wird man kaum eine Option in den Compiler eingebaut haben um das Padding zu deaktivieren.

    Aber der Grund ist nicht, Vergleiche einfacher zu machen.



  • SeppJ schrieb:

    Autowech schrieb:

    SeppJ schrieb:

    Autowech schrieb:

    Konnte man nicht das Padding ausschalten und/oder per Hand erledigen? Automatismen sind ja nicht immer wünschenswert.

    Könnte man, aber wieso sollte man das wollen? Bloß um beim Vergleich faul sein zu dürfen? Das Padding ist ja nicht bloß da, um den Programmierer zu ärgern.

    Umsonst wird man kaum eine Option in den Compiler eingebaut haben um das Padding zu deaktivieren.

    Aber der Grund ist nicht, Vergleiche einfacher zu machen.

    Aber würde das fehlende Padding nicht den Vergleich von Strukturen mit memcmp auch schneller machen?



  • Jo, und alles andere, was mit den Strukturen, bzw. Zugriffen auf die Member zu tun hat, langsamer ...



  • Autowech schrieb:

    Aber würde das fehlende Padding nicht den Vergleich von Strukturen mit memcmp auch schneller machen?

    Aber das würdest Du Dir ja zu Ungunsten des Compilers erkaufen, der die Struktur nicht nach seinem Gusto optimieren darf.

    Abgesehen davon ist der bitweise Vergleich relativ schnell uninteressant - z.B. bei Zeigern oder strings in char[] .



  • Autowech schrieb:

    Aber würde das fehlende Padding nicht den Vergleich von Strukturen mit memcmp auch schneller machen?

    Tatsächlich kann das Padding den Vergleich sogar schneller machen. Wenn das Padding eine Struktur beispielsweise von 56 auf 64 Bit vergrößert, kann der Compiler das memcmp eventuell mit einem 64-bit cmp umsetzen, anstatt mit drei cmp , die jeweils 32, 16 und 8 Bit umfassen. Das setzt natürlich voraus, dass der Compiler an der Stelle die Werte der Padding-Bytes kennt. Da deren Werte aber implementationsdefiniert sind, kann ein Compiler da einiges machen.

    Das Einsparpotential durch den Verzicht auf Padding ist nie so groß, dass es Operationen auf einzelnen Instanzen beschleunigen könnte. Man kann Strukturelemente immer so umsortieren, dass ein minimales Padding am Ende der Struktur entsteht. Wenn die Struktur zum Beispiel ein Alignment von 8 erfordert, kann maximal Padding-Overhead von 7 entstehen.

    Wenn eine Struktur Padding hat, ist ein einfaches memcmp natürlich sinnlos, weil das Ergebnis unvorhersehbar ist.
    Denkbar wäre aber eine Compiler-Erweiterung, die das memcmp des relevanten Anteils erlaubt.

    struct s
    {
    	uint32_t a;
    	/*_Padding(0) verbietet es dem Compiler das Offset eines Elementes durch Padding zu verändern.*/
    	_Padding(0) uint16_t b;
    	_Padding(0) uint8_t c;
    
    	/*Falls die Struktur für das Alignment Padding erfordert, muss dieses hinter end eingefügt werden.
    	  end zeigt dann genau auf den Beginn des eventuellen Paddings.*/
    	_Padding(0) char padding[];
    };
    
    struct s first, second;
    /*end beginnt genau da, wo der sinnvoll vergleichbare Anteil der Struktur aufhört*/
    memcmp(&first, &second, offsetof(struct s, padding));
    


  • Ok, dann scheint deaktiviertes Padding wirklich nur Sinn zu machen, wo man auf jedes Byte achten muss.

    Ich habe mal gelesen, dass es eh darauf ankommt cachefreundlich zu programmieren. Es hieß man sollte jeden Zugriff auf den wirklich langsamen Hauptspeicher vermeiden soll. Kontrolle ist also alles bei der Optimierung.


  • Mod

    Der Haupteinsatzzweck ist eher, dass man durch Abschalten des Paddings ein 100% vorhersehbares Layout der structs erreicht (gleiche Größe der Datentypen vorausgesetzt), so dass dieses garantiert binärkompatibel zwischen unterschiedlichen Plattformen ist (gleiche Endianess und ähnliches vorausgesetzt).



  • SeppJ schrieb:

    Der Haupteinsatzzweck ist eher, dass man durch Abschalten des Paddings ein 100% vorhersehbares Layout der structs erreicht (gleiche Größe der Datentypen vorausgesetzt), so dass dieses garantiert binärkompatibel zwischen unterschiedlichen Plattformen ist (gleiche Endianess und ähnliches vorausgesetzt).

    Mit anderen Worten, es ist gar nichts garantiert.
    Man spart sich lediglich etwas Tipparbeit, wenn man sich auf plattformspezifische Details verlässt.



  • Alignment ist schon wichtig. Man kann mit Beachtung der Pipeline und des Caches bis zu einem Faktor 100 an Geschwindigkeit rausholen. Das sind Handoptimierungen des Algos, welche auf die jeweilig CPU zugeschnitten sind, ohne jetzt Assembler nutzen zu müssen. Das sind aber keine Optimierungen, die der Compiler machen kann, da ein Compiler keine Algos anpassen kann, er kennt das große Ganze dahinter ja nicht. Es gibt darüber ein Video "Sehr schnelles Rechnen", wo versucht wird so etwas auch zu automatisieren, in einigen Fällen werden sogar Bereiche in Libs wie die von IPP Intel geschlagen.

    Schön an dem Video ist aber auch das mal Pipeline und Cache auf Deutsch erklärt wird.

    Video sehr schnelles Rechnen:
    http://www.multimedia.ethz.ch/speakers/lecture/?doi=10.3930/ETHZ/AV-d1c72caf-76ef-4834-b0b5-7350edf25710&autostart=true


Anmelden zum Antworten