spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »Legend«

Auf einer anderen Platform richtet der Compiler die Struktur vielleicht an nem anderen Alignment aus. Und dann ließt du nicht mehr die Daten richtig ein. Das ließe sich noch beheben, in dem man das Alignment vorgibt. Aus Effizienzgründen würde ich das aber für eine Vektorklasse aber vielleicht nicht tun.

Hast du zufällig konkrete Beispiele dafür, wie das wo standardmäßig aussieht? Ich meine, mit Binärdateien gibt es eine Menge Probleme, Datentypen können auch unterschiedlich groß sein, die Bitreihenfolge kann unterschiedlich sein und unterschiedliche Prozessoren können komplett unterschiedliche Darstellungen z.B. für Fließkommazahlen benutzen. Die Frage ist halt, ob das nur auf exotischen Plattformen passiert, oder ob das bei eines von den Problemen tatsächlich andauernd auftritt. Da kenn ich mich jetzt nicht wirklich aus, deswegen hätte ich gerne Beispiele dafür.

Textdateien sind generell sehr viel robuster und haben andere Vorteile. Aber Binärdateien sind halt um ein so vielfaches schneller, bzw. können es sein. Wenn man Für jedes Objekt eine Speicherfunktion aufrufen muss, die intern für jede Variable Funktionen aufruft und vielleicht noch Dinge hin und herkopiert, belastet das die CPU und den Hauptspeicher und so viel mehr, wie wenn man einfach sagt "Hier hast du 5MB, knall mir die bitte auf die Platte." Sowas kann sich schon mehr als spürbar auf die Ladezeiten auswirken.
Das geht aber halt nicht immer, zum Beispiel wenn man komplexe Datenstrukturen benutzt, oder wenn man eben recht unterschiedliche Plattformen unterstützen will. Aber nur deswegen würde ich doch nicht kategorisch darauf verzichten.

Zitat von »Jonathan_Klein«

Zitat von »Legend«

Auf einer anderen Platform richtet der Compiler die Struktur vielleicht an nem anderen Alignment aus. Und dann ließt du nicht mehr die Daten richtig ein. Das ließe sich noch beheben, in dem man das Alignment vorgibt. Aus Effizienzgründen würde ich das aber für eine Vektorklasse aber vielleicht nicht tun.

Hast du zufällig konkrete Beispiele dafür, wie das wo standardmäßig aussieht? Ich meine, mit Binärdateien gibt es eine Menge Probleme, Datentypen können auch unterschiedlich groß sein, die Bitreihenfolge kann unterschiedlich sein und unterschiedliche Prozessoren können komplett unterschiedliche Darstellungen z.B. für Fließkommazahlen benutzen. Die Frage ist halt, ob das nur auf exotischen Plattformen passiert, oder ob das bei eines von den Problemen tatsächlich andauernd auftritt. Da kenn ich mich jetzt nicht wirklich aus, deswegen hätte ich gerne Beispiele dafür.

Textdateien sind generell sehr viel robuster und haben andere Vorteile. Aber Binärdateien sind halt um ein so vielfaches schneller, bzw. können es sein. Wenn man Für jedes Objekt eine Speicherfunktion aufrufen muss, die intern für jede Variable Funktionen aufruft und vielleicht noch Dinge hin und herkopiert, belastet das die CPU und den Hauptspeicher und so viel mehr, wie wenn man einfach sagt "Hier hast du 5MB, knall mir die bitte auf die Platte." Sowas kann sich schon mehr als spürbar auf die Ladezeiten auswirken.
Das geht aber halt nicht immer, zum Beispiel wenn man komplexe Datenstrukturen benutzt, oder wenn man eben recht unterschiedliche Plattformen unterstützen will. Aber nur deswegen würde ich doch nicht kategorisch darauf verzichten.

Das ist jetzt zwar eine Option zum Alignment des Stacks und nicht einer Struktur, aber GCC hat schon andere Defaults für x86 und x64 (aus http://gcc.gnu.org/onlinedocs/gcc-3.4.4/…64-Options.html):

Zitat

-mpreferred-stack-boundary=num Attempt to keep the stack boundary aligned to a 2 raised to num byte boundary. If -mpreferred-stack-boundary is not specified, the default is 4 (16 bytes or 128 bits), except when optimizing for code size (-Os), in which case the default is the minimum correct alignment (4 bytes for x86, and 8 bytes for x86-64).
On Pentium and PentiumPro, double and long double values should be aligned to an 8 byte boundary (see -malign-double) or suffer significant run time performance penalties. On Pentium III, the Streaming SIMD Extension (SSE) data type __m128 suffers similar penalties if it is not 16 byte aligned.

Edit: Grad was besseres gefunden: http://en.wikipedia.org/wiki/Data_struct…_structs_on_x86

Zitat

The only notable difference in alignment for a 64-bit system when compared to a 32-bit system is:

• A long (eight bytes) will be 8-byte aligned.
  
• A double (eight bytes) will be 8-byte aligned.
  
• A long double (eight bytes with Visual C++, sixteen bytes with GCC) will be 8-byte aligned with Visual C++ and 16-byte aligned with GCC.
  
• Any pointer (eight bytes) will be 8-byte aligned.

Die zerlegen dir auch ein korrektes Laden, und long double (auch wenn selten benutzt) produziert unterschiedliches Alignment mit Visual C++ und GCC.

Zitat von »Jonathan_Klein«

Wo ist das Problem mit Alignment? Das die Datei ein wenig größer wird?

Nein, sondern dass das eigentliche Format der Datei damit nicht definiert ist. Wenn ein anderer Compiler den selben Code übersetzt, ist nicht vorhersagbar, ob das übersetzte Programm die Datei lesen kann oder nicht. Und das ist schlecht. Sehr schlecht sogar.
Edit: Ah ja, erst lesen, dann posten Details wurden oben ja schon benannt.

Zitat von »Jonathan_Klein«

Und wo ist das Problem mit Referenzen? Außer dass die zweite Funktion natürlich nicht kompiliert weil ich copy'n'paste benutzt habe und der vector konstant ist.

Der Code würde kompilieren, da ich von Referenz-Member-Variablen in der Klasse rede, die als Datentyp im Vektor liegt. Es würden Speicher-Adressen in der Datei landen und beim Auslesen invalide Speicheradressen gelesen werden. Auch das wurde aber scheinbar schon erwähnt.
Zusätzlich wurde ja auch schon das Problem der unterschiedlich großen Datentypen erwähnt und dann gibt es natürlich auch noch BigEndian und LittleEndian. Das alles macht dir ganz schnell alles zu Sau, also ganze Datentypen unvorsichtig streamen ist eine ungute Idee. Selbst wenn Endians keine Rolle spielen, weil es eh nur auf einer x86 CPU laufen soll, GCC und VC++ haben bei Datentypen-Längen und Alignments ganz verschiedene Auffassungen. Selbst wenn man sagt, man will ohnehin nur mit VC++ arbeiten, niemand garantiert einem (afaik), dass die nächste VC-Version keine anderen Alignments verwendet. Und damit wäre man dann eventuell an einen alten Compiler gebunden, damit das Programm überhaupt noch mit den schon erstellten Daten lauffähig wäre. Das würde ich als Entwickler wirklich nicht riskieren wollen.

Zitat von »Legend«

A long double (eight bytes with Visual C++, sixteen bytes with GCC) will be 8-byte aligned with Visual C++ and 16-byte aligned with GCC.

Hm, aber das ist nicht direkt ein Alignment Problem, sondern ein Problem von unterschiedliche großen Variablen, oder nicht? Da hat man dann beim binären Speichern eh schon Probleme.

Zitat von »BlueCobold«

Der Code würde kompilieren, da ich von Referenz-Member-Variablen in der Klasse rede, die als Datentyp im Vektor liegt. Es würden Speicher-Adressen in der Datei landen und beim Auslesen invalide Speicheradressen gelesen werden.

Ah ok, jetzt weiß ich, was du meintest. Das wollte ich eigentlich auch mit "Das geht natürlich nur, wenn man CPersonen einfach so binär rausschreiben kann." angedeutet haben, da hätte man wohl mehr zu sagen müssen.

Mir fällt gerade noch ein, dass es neben diesen Alignment Problem ja auch noch sowas wie die vtable und so gibt. Man muss sich also wirklich einige Gedanken machen, welche Objekte man einfach so binär wegschreiben kann. POD Typen. Um sich als Anfänger aber klar zu machen, was im Hintergrund so alles passiert, ist das explizite speichern aller Variablen aber dann wohl geschickter.

Aber naja, wenn du mal ein vector<float> oder so speichern willst, kannst du ja meinen Vorschlag immer noch nehmen

Zitat von »Jonathan_Klein«

Zitat von »Legend«

A long double (eight bytes with Visual C++, sixteen bytes with GCC) will be 8-byte aligned with Visual C++ and 16-byte aligned with GCC.

Hm, aber das ist nicht direkt ein Alignment Problem, sondern ein Problem von unterschiedliche großen Variablen, oder nicht? Da hat man dann beim binären Speichern eh schon Probleme.

Nein, Alignment ist wieder was anderes. Stell Dir vor Du hast folgendes Struct:


Dann steht das x vermutlich an Adresse 0 bei beiden Compilern, aber das a steht bei VC++ an Adresse 8 und bei GCC an Adresse 16. Die floats können trotzdem beide 4 Byte lang sein. Damit wären nicht nur die Variablen an verschiedenen Adressen, sondern die Structs auch noch unterschiedlich groß, was dann erst zu so richtig Ärger beim Auslesen führt

Ja, das weiß ich ja. Was ich sagen wollte war, dass man, wenn die Variablen schon unterschiedlich groß sind, eh Probleme hat und nicht erst welche durchs Alignment bekommt (wobei die dann natürlich noch dazu kommen können, aber dann ist ja eh schon alles verloren).

Man muss ja auch nicht sowas exotisches nehmen wie einen long double

Ich hab auch mal von Optimierungen gelesen, bei denen die Reihenfolge der Felder in ner Struct verändert werden kann, aber ich finds nicht mehr.