Objekt im Speicher verschieben ; Speicherabbild erstellen

[sqrt(-1)]

Registrierter Troll schrieb:

In welche Form man die Daten letztendlich bringt, ist doch nebensächlich und hängt letztendlich davon ab, was man damit machen will.

Ich sehe das anders wenn man die Petawatt an Energie betrachtet, die nur deswegen anfallen weil Daten und Strukturen in Textformaten zwischengespeichert werden.

Textformate sind oft erste Wahl, weil sie leicht zu debuggen sind und man sich nicht mit Problemen wie Endianess oder Datenwortbreiten rumschlagen muss.

Das Textformate "leicht zu debuggen sind" ist doch eine absolute Nullaussage. Klar kann ich eine Konfiguration.txt lesen und eine Konfiguration.dat nicht. Bei OfficeDatei.xml ist es wieder absolut hinfällig.

Probleme wie Endianess und Datenwortbreite sind kein Grund für ein Textformat.

[Nexus]

sqrt(-1) schrieb:

Ich sehe das anders wenn man die Petawatt an Energie betrachtet, die nur deswegen anfallen weil Daten und Strukturen in Textformaten zwischengespeichert werden.

Denk mal an die vielen Probleme, die behoben oder umgangen werden müssten, wenn alles nur noch binär gespeichert würde (welche, wurde ja genannt). Und überlege dir, ob man für den Mehraufwand, ein halbwegs portables Binärformat zu realisieren, auch Energie braucht.

sqrt(-1) schrieb:

Probleme wie Endianess und Datenwortbreite sind kein Grund für ein Textformat.

Das kannst du sicher begründen.

[volkard]

Nexus schrieb:

sqrt(-1) schrieb:

Probleme wie Endianess und Datenwortbreite sind kein Grund für ein Textformat.

Das kannst du sicher begründen.

Wozu? Es sind keine Gründe. Wie will er begründen, was gar keinen Halt hat?
Er kann nur Theorien widerlegen, die behaupten, man bräuchte wegen Endianess oder Datenwortbreite ein Binärformat. Dazu muß jemand begründen, weshalb er ein Textformat braucht und diese Begründung kann leicht zerfetzt werden.

[sqrt(-1)]

[quote="Nexus"]Denk mal an die vielen Probleme, die behoben oder umgangen werden müssten, wenn alles nur noch binär gespeichert würde (welche, wurde ja genannt). Und überlege dir, ob man für den Mehraufwand, ein halbwegs portables Binärformat zu realisieren, auch Energie braucht.

Der Leistungsaufwand ist um Größenordnungen geringer. Was soll denn daran komplizierter sein die Auszeichnung von Daten und Strukturen mittels Binärdaten anstatt von Text zu realisieren?

sqrt(-1) schrieb:

Probleme wie Endianess und Datenwortbreite sind kein Grund für ein Textformat.

Das kannst du sicher begründen.

Es ist doch simpel auch plattformunabhängig binär zu beschrieben in welchem Platformformat die Daten vorliegen um dann gegebenfalls Anpassungen beim Interpretieren vorzunehmen.

[sqrt(-1)]

Nexus schrieb:

Denk mal an die vielen Probleme, die behoben oder umgangen werden müssten, wenn alles nur noch binär gespeichert würde (welche, wurde ja genannt). Und überlege dir, ob man für den Mehraufwand, ein halbwegs portables Binärformat zu realisieren, auch Energie braucht.

Der Leistungsaufwand ist um Größenordnungen geringer. Was soll denn daran komplizierter sein die Auszeichnung von Daten und Strukturen mittels Binärdaten anstatt von Text zu realisieren?

Nexus schrieb:

sqrt(-1) schrieb:

Probleme wie Endianess und Datenwortbreite sind kein Grund für ein Textformat.

Das kannst du sicher begründen.

Es ist doch simpel auch plattformunabhängig binär zu beschrieben in welchem Platformformat die Daten vorliegen um dann gegebenfalls Anpassungen beim Interpretieren vorzunehmen

[Registrierter Troll]

volkard schrieb:

Wozu? Es sind keine Gründe. Wie will er begründen, was gar keinen Halt hat?
Er kann nur Theorien widerlegen, die behaupten, man bräuchte wegen Endianess oder Datenwortbreite ein Binärformat. Dazu muß jemand begründen, weshalb er ein Textformat braucht und diese Begründung kann leicht zerfetzt werden.

Bitte lesen lernen. Hier steht nirgends, dass man deswegen Textformate braucht, sondern dass man mit Textformaten weniger Probleme dieser Art hat.

Die Gründe liegen auf der Hand: Die Bedeutung von ASCII-Text bleibt eindeutig, auch wenn er auf verschiedenen Plattformen eingelesen wird. Von ganz exotischen Ausnahmen mal abgesehen. Der gleiche Parser kann somit auf vielen verschiedenen Plattformen unverändert verwendet werden.

[unskilled]

sqrt(-1) schrieb:

Nexus schrieb:

Denk mal an die vielen Probleme, die behoben oder umgangen werden müssten, wenn alles nur noch binär gespeichert würde (welche, wurde ja genannt). Und überlege dir, ob man für den Mehraufwand, ein halbwegs portables Binärformat zu realisieren, auch Energie braucht.

Der Leistungsaufwand ist um Größenordnungen geringer. Was soll denn daran komplizierter sein die Auszeichnung von Daten und Strukturen mittels Binärdaten anstatt von Text zu realisieren?

Nexus schrieb:

sqrt(-1) schrieb:

Probleme wie Endianess und Datenwortbreite sind kein Grund für ein Textformat.

Das kannst du sicher begründen.

Es ist doch simpel auch plattformunabhängig binär zu beschrieben in welchem Platformformat die Daten vorliegen um dann gegebenfalls Anpassungen beim Interpretieren vorzunehmen

boar..
jz google(oder bing(?!^^) oder such direkt bei wikipedia oder was auch immer) halt endlich mal nach endianess und datenwortbreite! (mit floating-point values wirds dann ganz lustig, weil dir der standard da(im Bezug auf den internen Aufbau) rein gar nichts garantiert xD)
es ist eben _kein_ triviales problem...

Performance ist zwar ein nicht von der Hand zu weisendes "Problem", aber was schreibst du denn für ein Programm, dass es so extrem schnell gehen muss?

bb

[sqrt(-1)]

Es ist doch offensichtlich das die Auszeichnung von Daten mittels Text bis auf die theoretisch bessere menschliche Lesbarkeit absolut Null Vorteile, aber viele Nachteile mit sich bringt. Denn letztendlich ist Text ja auch nur ein Format für Binärdaten.

Dass Datenstrukturen als Text gelesen werden können erachte ich für nicht triviale Falle (wie Konfigurationsdateien) als ganz klar nicht amortisierend, da die Strukturen sowieso dokumentiert sind oder gar die Interpretationsalgorithmen vorliegen. Dass man mit Textformaten etwas einfacher reverse-engineering betreiben kann halte ich für keine Begründung das (professionell) einzusetzen.

[volkard]

Ich schreibe gern als Text hex statt dez und spare mir damit die Divisionen. Daß ich 2 Ziffern statt einer pro Byte Nutzdaten brauche, stört mich weniger.

[sqrt(-1)]

unskilled schrieb:

boar..
jz google(oder bing(?!^^) oder such direkt bei wikipedia oder was auch immer) halt endlich mal nach endianess und datenwortbreite! (mit floating-point values wirds dann ganz lustig, weil dir der standard da(im Bezug auf den internen Aufbau) rein gar nichts garantiert xD)
es ist eben _kein_ triviales problem...

Es geht doch nur darum ob es einfacher ist binär oder im Textformat das Platformformat der Daten zu beschreiben. Was da an Standardisierungkomplexität dahinter steht ist doch in beiden Fällen identisch.

Performance ist zwar ein nicht von der Hand zu weisendes "Problem", aber was schreibst du denn für ein Programm, dass es so extrem schnell gehen muss?

Um meine Person müssen wir uns doch an der Stelle nicht kümmern.

[Registrierter Troll]

sqrt(-1) schrieb:

Es ist doch offensichtlich das die Auszeichnung von Daten mittels Text bis auf die theoretisch bessere menschliche Lesbarkeit absolut Null Vorteile, aber viele Nachteile mit sich bringt.

Ich warte gespannt auf die Aufzählung dieser vielen offensichtlichen Nachteile, die mir irgendwie zu entgehen scheinen.

[sqrt(-1)]

Registrierter Troll schrieb:

Ich warte gespannt auf die Aufzählung dieser vielen offensichtlichen Nachteile, die mir irgendwie zu entgehen scheinen.

- höherer Rechenleistungsaufwand
- größerer Speicheraufwand
- zusätzliche Komplexität des Parsers
- verleitet die Dokumentation zu Vernachlässigen

[Nexus]

Das beginnt langsam in einen Flamewar auszuarten. sqrt(-1), wir sagen nicht, Binärformate seien grundsätzlich schlechter. Natürlich gibt es berechtigte Anwendungsfälle. Du behauptest aber, dass sie Textformaten immer überlegen sind. Portabilität ist damit eindeutig aufwändiger, das beginnt ja bereits damit, dass du ein standardisiertes Format brauchst, um zu entscheiden, in welchem Binärformat die eigentlichen Informationen gelesen werden sollen.

Du kannst natürlich sowas wie ein neues, standardisiertes Binärformat erzeugen. Dann bist du aber wieder nahe am Textformat und hast die entsprechenden Nachteile: Mehr Aufwand, weil bitweise gefrickelt werden muss und teilweise redundante Informationen. Trotzdem musst du auf sehr viele implementierungsspezifische Dinge Rücksicht nehmen. Im Bezug auf C++ heisst das, dass du oft undefiniertes Verhalten hast.

Da mit Textformaten wie Unicode bereits internationale Konventionen existieren, ist Portabilität damit um einiges einfacher. Auch ist ein besserer Austausch möglich, wenn es sich um ein etabliertes Format handelt.

[unskilled]

sqrt(-1) schrieb:

Registrierter Troll schrieb:

Ich warte gespannt auf die Aufzählung dieser vielen offensichtlichen Nachteile, die mir irgendwie zu entgehen scheinen.

- höherer Rechenleistungsaufwand
- größerer Speicheraufwand
- zusätzliche Komplexität des Parsers
- verleitet die Dokumentation zu Vernachlässigen

- höherer Rechenleistungsaufwand
vernachlässigbar (hdd-zugriff dauert ja wohl um größenordnungen länger als nen paar cpu-takte)
- größerer Speicheraufwand
also ob ein Programm nun ne große Datei oder eine halb so große große Datei erstellt, ist mir relativ wurst...
ist aber in meinen augen der einzige wirkliche nachteil(da es mehr zu schreiben/lesen gibt, dauert es auch länger - wobei der flaschenhals ja das lesekopf positionieren und nicht das lesen an sich sein wird...
- zusätzliche Komplexität des Parsers
der binäre parser würde sicherlich ähnlich komplex sein... vrmtl so gar noch komplexer...
- verleitet die Dokumentation zu Vernachlässigen
was nen nachteil...

bb

[Registrierter Troll]

sqrt(-1) schrieb:

- höherer Rechenleistungsaufwand

Das ist doch angesichts der vorhandenen Rechenpower schon seit Jahren ein vernachlässigbarer Faktor. Ob das Parsen 10 ms oder 100 ms dauert ist in den wenigsten Fällen relevant.

- größerer Speicheraufwand

Hierfür gilt das Gleiche. Speicher ist reichlich vorhanden.

- zusätzliche Komplexität des Parsers

Wenn man mal von C++ ausgeht, ist alles schon an Board was man dazu braucht. Einen einfacheren und portableren Parser als einen der Text liest, wirst du kaum schreiben können. Und du musst ihn nicht für jede Plattform anpassen.

- verleitet die Dokumentation zu Vernachlässigen

Das ist eine haltlose Behauptung ohne jede Substanz.

Man muss nicht alles unbedingt in ein Textformat zwängen, das stimmt schon. Bitmaps würde ich so nicht speichern.
Aber für viele Fälle ist es nun mal das Einfachste, und es macht den geringsten Aufwand.

[Nexus]

Mit dem Argument, dass heutige RAM/Prozessoren so gut sind, dass es nicht mehr auf Performance ankommt, wäre ich sehr vorsichtig (ist übrigens eines der Standardargumente von C++-Bashern). Das mag zwar in vielen Fällen stimmen, trotzdem sollte man versuchen, im vernünftigen Rahmen effizient zu programmieren. 10ms oder 100ms mag tatsächlich egal sein, ob es einen oder zehn Tage dauert vielleicht weniger.

Das meine ich jetzt eher allgemein. Doch je nach Anwendung kann der Einsatz binärer Formate durchaus durch die grössere Geschwindigkeit motiviert sein.

[volkard]

Wenn ich einen Stream mit strukturieten Daten schnell schreiben und lesen will, also sehr schnell, ist das Standardvorgehen eh nicht so optimal. Ein paar kleine Tricks muß ich schon machen. Insbesondere muß ich Konstruktoren benutzen. Weil das bei eingebauten Typen nicht geht, für die ein Umweg dazu. Das konstruietre Codebeispiel machts deutlich:

class Derived:public Base{
   Foo f;
   int i;
   string s;
   Array<int,10> a;
   Vector<int> v;
public:
   Derived(istream& in):
      Base(in),
      f(in),
      i(readInt(in)),
      s(readString(in)),
      a(in),
      v(in){
      }
   void saveTo(ostream& out){//virtual in Base
      Base::saveTo(out);
      f.saveTo(out);
      writeInt(i,out);//ist nur out<<i<<'\n'
      writeString(i,out);//schreibt z.B. "hallo" oder 5:hallo
      a.saveTo(out);
      v.saveTo(out);
   }
};

Die Geschwindigkeit ist erprobt und enorm. Es ist null problemo, beim Schreiben auch den Klassennamen davorzuschreiben, damit eine lesende Factory das dann richtig zuordnen kann. Es ist auch kein Problem, da noch ein klitzbißchen zu erweitern, daß am Ende in der Datei so Sachen stehen:

Mob{
  ID=4ff3ab0
  Name=16:Conan der Barbar
  Position{
    x=3456
    y=334
  }
  Backpack{
    6:32f7,4480,32fa0b,deadbeef,123,8678333
  }
}

Dazu ist es nur nötig, die Schnittstelle zu ändern zu

void saveTo(ostream& out,char const* name,int ident);

und saveTo ruft in allen Unteraufrufen halt was wie poition.saveTo("Position",ident+2) auf. Man beachte, daß Stringgrößen und Arraygrößen immer vorher stehen, damit der Konstruktor erst allokieren und dann lesen kann. Wo andere für einen Spielstand 30 Minuten brauchten, war ich in 30 Sekunden durch. Aber das habe ich zuletzt vor 10 Jahren gemacht, ich vermute aber, die Technik ist noch nicht schlecht geworden.

Automatisch ist die Erweiterung für Binärstreams eingebaut.

class Derived:public Base{
   Foo f;
   int i;
   string s;
   Array<int,10> a;
   Vector<int> v;
public:
   Derived(istream& in):
      Base(in),
      f(in),
      i(readInt(in)),
      s(readString(in)),
      a(in),
      v(in){
      }
   Derived(BinaryInputStream& in):
      Base(in),
      f(in),
      i(readInt(in)),
      s(readString(in)),
      a(in),
      v(in){
      }
   void saveTo(ostream& out){//virtual in Base
      Base::saveTo(out);
      f.saveTo(out);
      writeInt(i,out);//ist nur out<<i<<'\n'
      writeString(i,out);//schreibt z.B. "hallo" oder 5:hallo
      a.saveTo(out);
      v.saveTo(out);
   }
   void saveTo(BinaryOutputStream& out){//virtual in Base
      Base::saveTo(out);
      f.saveTo(out);
      writeInt(i,out);//ist nur out<<i
      writeString(i,out);//schreibt z.B. "hallo" oder \5hallo
      a.saveTo(out);
      v.saveTo(out);
   }
};

Damit kann man dann die 30 Sekunden vermutlich noch ein wenig drücken, obwohl ich es immer nur als Option freigehalten habe, die ich dann doch nicht benutzte. Die meiste Zeit wird bei sowas eh für new-Aufrufe in Strings oder Vectoren verbraten und für Hashtable- oder map-Nachguckerchen, um Zeigerverknüpfungen zu bauen.

Fazit meinerseites: Es ist meistens nicht notwendig, binär zu speichern, aber es tut auch nicht weh, es ist kein Zusatzausfwand und es ist nicht unmöglich.

[volkard]

Es ist nicht zu vernachlässigen, wie schnell Festplatten Daten liefern können.
Ich habe mir ein Programm gebaut, das auf der Platte Duplikate sucht und immer wenn in C:\toMove\... eine Datei ist, die auch woanders in C:\... ist, mir die aus C:\toMove\... löscht. Dazu vergleicht es erst Dateigrößen, nur bei gleichgroßen Dateien berechnet es Checksummen, nur bei gleichen Checksummen vergleicht es byteweise die beiden Dateien und nur wenn sie byteweise gleich sind, löscht er die aus C:\toMove\....
Oh, meine Platte hat es nötig. Zuerst hatte ich für die Checksummen x=x*compilezeitkonstanteprimzahl+readByte() genommen. Aber das hatte eine Prozessorauslastung von konstant 100%. Jetzt nehme ich CRC64 und die Prozessorauslastung wackelt ein wenig über der Kernelprozessorauslastung(zwischen 80 und 100) rum.

Mein Fazit: Die Platte ist so sagenhaft schnell, wenns um sequentielles lesen/schreiben geht, da0 es doch kein blanker Unfug ist, sein Programm auch schnell zu machen.

[Registrierter Troll]

Nexus schrieb:

Mit dem Argument, dass heutige RAM/Prozessoren so gut sind, dass es nicht mehr auf Performance ankommt, wäre ich sehr vorsichtig (ist übrigens eines der Standardargumente von C++-Bashern). Das mag zwar in vielen Fällen stimmen, trotzdem sollte man versuchen, im vernünftigen Rahmen effizient zu programmieren.

Klar kommt es irgendwann auf die Performance an, aber man kann in der Regel schon eine ganze Menge Text parsen, bevor man überhaupt mal in einen Bereich kommt, wo es einen fühlbaren Unterschied zum binären Lesen gibt.
Ich will auch gar nichts gegen Binär gesagt haben, ich halte bloß Text bei Vielem für das bessere Default und die genannten Gegenargumente dagegen für sehr schwach.

volkard schrieb:

Es ist auch kein Problem, da noch ein klitzbißchen zu erweitern, daß am Ende in der Datei so Sachen stehen:

Das sieht fast schon aus wie JSON, was ich gerne und oft benutze.

[volkard]

Registrierter Troll schrieb:

volkard schrieb:

Es ist auch kein Problem, da noch ein klitzbißchen zu erweitern, daß am Ende in der Datei so Sachen stehen:

Das sieht fast schon aus wie JSON, was ich gerne und oft benutze.

JSON hörte ich gerade zum ersten mal. google google...
Ahh. Halt ein paar Minuten nachgedacht und man hat mehr Menschenlesbarkeit und Performance als XML. Wobei JSON noch weitere Vorzüge hat, die mich weniger betreffen.