Typumwandlung mit Union fehlerhaft?
-
Blue][ce schrieb:
Bin mir nicht sicher ob das wirklich einen Vorteil bringt.
Da wäre es doch eher sinnvoll sowas zu machen:union_rechnen.c[0] = fgetc(FDatei); union_rechnen.c[1] = fgetc(FDatei);
Bin mir nicht sicher, aber das sollte es ein wenig schneller machen...
Im Gegenteil, es führt zu schlechter Performance, Daten aus dem OS- Filesystem charweise zu holen.
Ist mir drastisch vor Augen geführt worden, als ich 'ne ASM- Routine ausm Controller unter XP nach C portiert und den Stream zur Simulation aus 'ner Datei geholt habe. Einzelne chars abzuholen und zusammenzubasteln kostet irre Rechenzeit. Bei kleinen Testdatensätzen war's wurscht, weil einem nicht auffällt, ob das Ding 0,1 oder 0,3 Sekunden läuft, bei großen Datenmengen spielt es dann schon eine Rolle, ob das Ding eine halbe oder anderthalb Minuten vor sich hinrattelt.
Nach Umpacken in eine Struct hat das Ding um Faktor 3 an Tempo zugelegt, ist zwar nur exemplarisch, dürfte sich aber allgemein in der Größenordnung bewegen. Also byteweise vom Filesystem zu lesen, ist ein echter PerformancekillerUnd die Typkonvertierung über 'ne Union zu machen hat sowieso die von fricky dargelegten Nachteile, so ^^^^^^ würdest Du alle Nachteile vereinen.
-
Blue][ce schrieb:
Was ist daran unportabel? Und wieso hack?
Unportabel deshalb, weil nicht eindeutig festgelegt ist, wie der Compiler seine unions und structs zu organisieren hat. Mit pack- pragmas kannst Du z.B. verschiedene Alignments erzwingen. Heißt, Du kannst nicht davon ausgehen, daß die gleiche Source auf verschiedenen Systemen die gleichen Daten erzeugt, die physikalisch auf Platte landen.
Noch eine Möglichkeit des Schiefgehens bietet die Little/BigEndian- Problematik.So ziemlich alles, was die Source an eine ganz bestimmte Compiler/HW-Plattform- Kombination bindet, bezeichnet man als Hack. In C löst man solche Sachen besser über defines auf, die explizit die Unterschiede klarmacht und schafft sich keine Probleme durch zunächst augenscheinlich unauffällige Codestückchen mitten in der Source.
-
Okay. Man lernt doch jeden Tag was dazu. Ich werd mir das mal durch den Kopf gehen lassen.
Bezüglich des Einlesens mittels Struct. Da kann ich mir leider garnichts drunter vorstellen. Könntest du ein Beispiel bringen?
Vielleicht gerade diese kurzen Zeilen ersetzen?for(m = 0; m < 2; m++){ union_rechnen.c[m] = fgetc(FDatei); }
Wäre sehr hilfreich, denn solche Stellen habe ich deutlich über 100x in meinem Quelltext und wenn das ein Performancekiller ist wie ihr sagt, wäre das von den ganzen Dingen für mich erstmal das wichtigste.
Danke.
Greez,
Blue][ce
-
Also wenn das was du aus der Datei einliest mehr als zwei Zeichen sind,
ist eine Optimierung dieser 3 Zeilen ein Tropfen auf den heißen Stein.
-
Diese Zeilen sollen mir ja nur helfen zu verstehen, wie ich das grundsätzlich besser machen kann. Ich will ja was lernen und nicht alles andere machen lassen. Aber mit Beispielen lernt es sich am einfachsten finde ich.
-
also mal im pseudo stil...
1. wir holen 4096 Zeichen bzw. weniger falls Dateiende aus der Datei und
speichern sie in nem char*
2. diesen String bearbeiten wir nun und schieben nach jedem schleifen Durchlauf
den Zeiger 2 Zeichen vor.
3. ab zu 1. oder fertig
-
Klingt zwar ganz nett, ist für meinen Fall aber nicht sonderlich praktikabel.Ich muß Dateien mit mehreren 100 MByte verwenden. Von diesen Daten benutze ich aber garnicht alle (nur fast) und leider auch nicht in der Reihenfolge wie sie in der Datei stehen.
-
Ohne die Datensätze zu kennen ists natürlich immer schwierig, dieser Meinung
bin ich allerdings immer noch, evtl. kann da jemand anders noch was dazu sagen.c_newbie schrieb:
/* for(m=0;m<2;m++){ union_rechnen.c[m]=fgetc(FDatei); } */ fread(union_rechnen.c,sizeof(union_rechnen.c[0]),2,FDatei);
-
Blue][ce schrieb:
Klingt zwar ganz nett, ist für meinen Fall aber nicht sonderlich praktikabel.Ich muß Dateien mit mehreren 100 MByte verwenden. Von diesen Daten benutze ich aber garnicht alle (nur fast) und leider auch nicht in der Reihenfolge wie sie in der Datei stehen.
Okay, fangen wir mal andersrum an:
Was genau steht in Deiner Datei überhaupt drin?
Und worin genau besteht die Nicht- Sequenzialität?Du hast zwei eigentlich voneinander unabhängige Probleme, einerseits die Typ- Konvertierung und andererseits den Dateizugriff.
Beim Dateizugriff ist es performanter, möglichst viele Daten über nur einen fread/fwrite an einen Betriebssystemaufruf zu binden; char- Zugriffe unbedingt meiden, wenn anders möglich.
Ich habe auch noch nicht ganz kapiert, warum Du nicht gleich union_rechnen.i[0] einlesen kannst, dann steht's ja eh schon als int drin.
-
@pointercrash
könnt schon sein dass das so besser wär, hast sowas schon mal getestet?
sonst werd ich das abends mal auf nen benchmark los lassen. könnt aber
auch identisch sein was ich fast tippen würd.fread(union_rechnen.c,sizeof(union_rechnen.c[0])<<1,1,FDatei); VS fread(union_rechnen.c,sizeof(union_rechnen.c[0]),2,FDatei);
-
c_newbie schrieb:
@pointercrash
könnt schon sein dass das so besser wär, hast sowas schon mal getestet?Sowas ähnliches, ja. Die "zwei in einem Rutsch" war viel schneller, wobei es bei mir eher zwanzig in einem Rutsch war.
-
Wunderschönen guten Morgen.
Zum Thema Quelldateien: Ich analysiere Messdateien, die bei der Fahrzeug-Steuergeräte-Kommunikation mitgeschrieben werden. Das Format nennt sich MDF-Format. Die Spezifikationen dieses Dateityps sind veröffentlicht, zu finden bei Vector Informatik.
Die Informationen liegen dabei in Blöcken in der Datei, wobei nicht spezifiziert ist an welcher Stelle sie liegen. Die Vernetzung der Blöcke erfolgt über eine dateiinterne Adresse.Die Daten über fread einzulesen klingt für mich durchaus sinnvoll, wenn ich dabei tatsächlich mit einem Geschwindigkeitsvorteil rechen kann.
Das Union zur Konvertierung zu nutzen mag bei Ints nicht sonderlich sinnvoll erscheinen, ich habe jedoch auch einige floats und doubles, die ich so ohne Rechenaufwand lesen kann.
Oder gibt es dazu auch etwas praktischeres? Mir ist nichts eingefallen.Die Bedenken bezüglich verschiedener Systeme auf denen die Source zu anderen Ergebnissen führt kann ich aus allgemeiner Sicht nachvollziehen. Ich bin mir nur nicht sicher, ob sich der Aufwand für mich lohnt nur für den unwahrscheinlichen Fall dass jemand mit meinem Quelltext irgendwann irgendwo das falsche Ergebnis bekommt.
Bitte nicht falsch verstehen, ich will schon was lernen und in gutem Stil programmieren und bin euch für Tipps und Hinweise in dieser Richtung sehr dankbar, aber ich bin kurz vor der Diplomarbeits-Abgabe. Vorteile für den Anwender des compilierten Programms sind im Moment wichtiger, als Vorteile für meinen möglichen Nachfolger auf Programmiererseite.Greez,
Blue][ce
-
Hab ich jetzt alle vergrault?
-
Blue][ce schrieb:
Hab ich jetzt alle vergrault?
Nee, nur schockiert
- ich werd' mir jetzt nicht auf gut Glück den ganzen vector- Kram runterladen und durchlesen.
Blue][ce schrieb:
... nennt sich MDF-Format. Die Spezifikationen dieses Dateityps sind veröffentlicht, zu finden bei Vector Informatik.
Die Informationen liegen dabei in Blöcken in der Datei, wobei nicht spezifiziert ist an welcher Stelle sie liegen. Die Vernetzung der Blöcke erfolgt über eine dateiinterne Adresse.Schön, dann hast Du ja schon die Chunks - immer mit fread reinholen und dann im Speicher analysieren.
Blue][ce schrieb:
Das Union zur Konvertierung zu nutzen mag bei Ints nicht sonderlich sinnvoll erscheinen, ich habe jedoch auch einige floats und doubles, die ich so ohne Rechenaufwand lesen kann.
Oder gibt es dazu auch etwas praktischeres? Mir ist nichts eingefallen.Bitte, dann nochmal: Char- weise die Daten in die Union zu füllen, um dann einen int oder double rauszulesen ist doof, weil langsam und unportabel. Unions/Structs in einem Rutsch einzulesen macht schon mehr Sinn.
Blue][ce schrieb:
Die Bedenken bezüglich verschiedener Systeme auf denen die Source zu anderen Ergebnissen führt kann ich aus allgemeiner Sicht nachvollziehen. Ich bin mir nur nicht sicher, ob sich der Aufwand für mich lohnt nur für den unwahrscheinlichen Fall dass jemand mit meinem Quelltext irgendwann irgendwo das falsche Ergebnis bekommt.
Klar, man denkt ja auch erst 1999 über ein mögliches Y2K- Problem nach.
Blue][ce schrieb:
Bitte nicht falsch verstehen, ich will schon was lernen und in gutem Stil programmieren und bin euch für Tipps und Hinweise in dieser Richtung sehr dankbar, aber ich bin kurz vor der Diplomarbeits-Abgabe. Vorteile für den Anwender des compilierten Programms sind im Moment wichtiger, als Vorteile für meinen möglichen Nachfolger auf Programmiererseite.
Geschwindigkeit würde ich schon als Vorteil für die Anwenderseite sehen, andererseits willst Du Deinen Kram mal abgeben und nen Schlußstich ziehen. Mir wird auch oft erst kurz vor Ende klar, wie man das von Anfang an besser hätte aufziehen können.
Wenn Dein Zeug läuft, behalte mal das charweise Lesen als Bremse und die Konvertierung über 'ne Union als Müll im Hinterkopf, gib's ab und hoffe, daß nie wieder jemand danach fragt.