Go Down

Topic: [gelöst] Warum ergibt sizeof(Data) immer ein Byte mehr? (Read 1 time) previous topic - next topic

HTML-Fan

Wie kann ich ihm mitteilen, dass das nicht mein Plan ist?

Tommy56

Na, indem Du nicht struct x in struct y einfügst. Wenn Du das machst solltest Du ja dafür einen bestimmten Grund gehabt haben oder es war schlicht unüberlegt, wenn Du das überhaupt nicht wolltest.

Das kannst im Endeffekt nur Du wissen.

Gruß Tommy
"Wer den schnellen Erfolg sucht, sollte nicht programmieren, sondern Holz hacken." (Quelle unbekannt)

michael_x

Hatten wir doch schon in #pragma pack(1) mit seinen Nachteilen ...

Ein ESP32 mag nun mal 32 bit Grenzen lieber, und braucht auch sonst schonmal mehr RAM als ein 8bit Controller. (Schonmal sizeof(char*) ausprobiert?)

HTML-Fan

Was aber, wenn ich zwei verschidene Instanzen des Types x in dem Typ y haben will? Muss ich dann alles als Array benutzen oder die Variablen kopieren und ein wenig umbenennen? Ich dachte eigentlich, dass structs dafür da sind, dass man einerseits alle Variablen in einem Objekt zusammenfassen kann und andererseits ein struct als Parameter für eine Funktion mitgeben kann. Zum Beispiel arbeite ich momentan mit einem Musikprogramm mit Oszillatoren, bei denen immer zwei Oszillatoren mit einem struct zusammengefasst werden (struct RingOsc{Osc osc1, osc2; ...};), damit man diese zwei Oszillatoren untereinander verstimmen und Ringmodulieren kann. Ich bin ja ein großer Fan vom SID-Chip und das sollte sowas wie ein SID 2.0 werden. Müsste ich jetzt osc1 und osc2 durch die ganzen Variablen, aus denen Osc besteht, ersetzen?

HTML-Fan

Argh!
Ich habe mir doch glatt die Antwort selber gegeben: Man kann es als Parameter mitgeben, also muss es ein zusammenhängender Haufen sein!  :smiley-confuse::smiley-red:

Tommy56

Oder mehrere Haufen in mehreren Parametern.

Gruß Tommy
"Wer den schnellen Erfolg sucht, sollte nicht programmieren, sondern Holz hacken." (Quelle unbekannt)

michael_x

Sei lieber froh, dass gelegentlich ein bool weniger als 32 bit braucht auf deinem ESP32 :)

HTML-Fan

Sei lieber froh, dass gelegentlich ein bool weniger als 32 bit braucht auf deinem ESP32 :)
Ich bin nicht in der Lage, meine extreme Begeisterung in Worte zu fassen.

Tommy56

@michael_x: Naja, man könnte ja 32 boolsche Werte in 32 Bit speichern ;)
Das hast Du aber sicher nicht gemeint.

Gruß Tommy
"Wer den schnellen Erfolg sucht, sollte nicht programmieren, sondern Holz hacken." (Quelle unbekannt)

combie

Nach dem ich mir das durchgelesen habe ....

Du solltest dich mit dem Padding arrangieren.
Und nicht auf Byte komm raus optimieren.

Die Verwendung von uint8_t und seinen Brüdern ist auf 16, 32 und 64 Bit Maschinen sehr dicht an Unsinn, da meist mit erheblicher Rechenlast verbunden.

int , ist das natürliche Maß der Dinge (außer auf den 8 Bit Dingern)

Tipp:
Für ungenutzten Speicher, gibts kein Geld zurück.
Gefährlich, was Theorien aus Menschen machen können.
Schlimmer, was Menschen aus Theorien machen.

HTML-Fan

@michael_x: Naja, man könnte ja 32 boolsche Werte in 32 Bit speichern ;)
Naja, das machen ja z.B. OLED-Libs und das sind ja die Sachen, die wirklich viel Speicher ziehen. Bei meinem vor Jahren programmierten Semi-Textadventure war es mir egal, ob "bool taschenlampeAn" und "bool wandEntdeckt" jeweils eigene Bytes verbrauchen.

HTML-Fan

Nach dem ich mir das durchgelesen habe ....

Du solltest dich mit dem Padding arrangieren.
Und nicht auf Byte komm raus optimieren.

Die Verwendung von uint8_t und seinen Brüdern ist auf 16, 32 und 64 Bit Maschinen sehr dicht an Unsinn, da meist mit erheblicher Rechenlast verbunden.

int , ist das natürliche Maß der Dinge (außer auf den 8 Bit Dingern)

Tipp:
Für ungenutzten Speicher, gibts kein Geld zurück.

Jaja, ich weiß. Alles ist eine Sache der richtigen Balance zwischen Cycle- und RAM-Verbrauch. Ich will jetzt nicht unbedingt 5 FPS gegen 50 Bytes tauschen. Es ging mir eher ums Prinzip. Solange ich ein Byte ohne Nachteile streichen kann, tue ich's natürlich. Und uint8_t und co ist auf einem ESP Stuss? Das zieht wirklich mehr Cycles pro Operationals uint32_t? Puh, hat sich die Welt seit dem 6502 weiterentwickelt. Ich weiß nicht, was ich davon halten soll. Und ich habe die ganze Zeit bei jeder Variable nachgedacht, ob nicht doch weniger Bytes reichen, denn das wird ja nur den positiven Effekt von gespartem RAM haben. Soviel dazu. Gilt das auch für uint8_t[]?

Tommy56

Tipp:
Für ungenutzten Speicher, gibts kein Geld zurück.
Der Tipp ist sehr gut.

Gruß Tommy
"Wer den schnellen Erfolg sucht, sollte nicht programmieren, sondern Holz hacken." (Quelle unbekannt)

HTML-Fan

Ach ja: Ist uint32_t besser als int32_t, wenn es um Geschwindigkeit geht?

combie

Quote
Puh, hat sich die Welt seit dem 6502 weiterentwickelt. Ich weiß nicht, was ich davon halten soll.
  • Natürlich geht die Entwicklung weiter
  • Und ebenso natürlich ist es beim 6502 nichts anders, als beim ESP


Merke:
Der natürliche Datentype lässt sich am schnellsten verarbeiten.
Exotische/künstliche Datentypen, müssen maskiert, geschoben und/oder sonstwie umgerechnet werden.

Beim 6502 sind die natürlichen Typen (8Bit) die schnellsten
Beim AVR sind die natürlichen Typen (8Bit) die schnellsten
Beim ESP sind die natürlichen Typen (32Bit) die schnellsten
Beim K210 sind die natürlichen Typen (64Bit) die schnellsten

Also:
Wenn du also meinst, da hätte sich was dran geändert, dann steckt da ein Irrtum.
Denn selbst zu 6502 Zeiten war das nicht anders, dir sind nur damals die 16, 26, 32, 36 Bit Rechner nicht begegnet.
Aber  "nicht begegnet" heißt nicht: "Gab es nicht"


Quote
Ach ja: Ist uint32_t besser als int32_t, wenn es um Geschwindigkeit geht?
Auch das ist Prozessorspezifisch.
Einzig bei int kann man sich sicher sein.
Nur nicht, ob int signed oder unsigned ist (Prozessorspezifisch).
Gefährlich, was Theorien aus Menschen machen können.
Schlimmer, was Menschen aus Theorien machen.

Go Up