[C/Bitwise] Kosten/Nutzen einer Einheit < 8 bit

[cwriter]

Hallo Welt

Meine Frage ist diesmal eher theoretischer Natur: Lohnt es sich, in 1 Byte mehrere Zahlwerte (mit logischerweise nur 2^4 (16) Möglichkeiten) zu packen?
So dass man zum Beispiel in ein BYTE den Wert 3 und in ein anderes BYTE den Wert 15 lädt und diese dann per >>= und |= zusammen in ein BYTE packt?
Logischerweise braucht das (zur Speicherung) weniger Platz, aber wie sieht das bei der CPU-Last aus?

Natürlich haben heutige Rechner so viel Power, dass man nicht wirklich auf die Last achten muss, doch gerade bezüglich der älteren Rechner: Lohnt sich diese Art von Speicheroptimierung zu Lasten der CPU? Oder wird die CPU ohnehin kaum belastet?

Als diskutables Beispiel führe ich hier mal 1'000'000 Elemente mit 4 Bytes als Alternative zu 1'000'000 Elementen mit 5 Bytes an.

Habt ihr damit schon irgendwelche Erfahrungen?
Ich freue mich auf jede Art von Anregung!

Gruss
cwriter

 

[Thomas Darimont]

Hallo,

es kommt darauf an - wenn du große Datenmengen auf kleinem Platz speichern möchtest ist das von dir genannte Verfahren eine gängige Möglichkeit um Speicherplatz und / oder Memory zu sparen.
Ein paar Bit/Ops zusätzlich tun IMHO nicht weh zumindest nicht der Maschine. Solche "Tricks" können jedoch zur höherer Code-Komplexität führen und sollten deshalb mit bedacht eingesetzt werden.

Siehe auch hier:
http://stackoverflow.com/questions/...-as-properties-with-one-byte-as-backing-field

Gruß Tom

 

[Caligulaminus]

Als diskutables Beispiel führe ich hier mal 1'000'000 Elemente mit 4 Bytes als Alternative zu 1'000'000 Elementen mit 5 Bytes an.

Damit würde ich 1/16 Promille meines RAMs sparen -> nur auf stark eingeschränkten Plattformen interessant.

 

[sheel]

Halb-OT:

Natürlich haben heutige Rechner so viel Power,
dass man nicht wirklich auf die Last achten muss

Bitte nicht, das stimmt genau so wenig wie vor 30 Jahren.
Die HW wird immer stärker, aber die SW braucht auch immer mehr Platz und Leistung
für die selben Sachen. Eben weil sich keiner mehr die Mühe macht, auf Effizienz zu achten.

Und das ist bei Gui-Zeug genau so bedeutend
(ich kann mich sehr über SW aufregen, die langsamer ist, als ich tippen/klicken kann.
Und ja, sowas kommt vor, allerdings nicht auf meinem Computer)
wie auch bei "Schwerarbeit" für den Rechner
(5 Stunden oder 40 Stunden komprimieren? Und ja, das ist nicht aus der Luft gegriffen)

@Caligulaminus: Man spart sich 20%... 4 im Vergleich zu 5.

 

[Caligulaminus]

@Caligulaminus: Man spart sich 20%... 4 im Vergleich zu 5.

Damit würde ich 1/16 Promille meines RAMs sparen

Ich bezog mich auf die Plattform.

 

[sheel]

Und ist dein Ram durch diese Datenmenge voll? Nein.
Du hast aber mehrere Programme, die auch Ram brauchen...
wenn alle dermaßen auf den Speicherverbrauch achten
hast du am Ende nur 80% Belegung im Vergleich zu einem voll ausgelastetem Ram.

@cwriter:
Wie schon gesagt wurde: Es kommt darauf an.
Ob sich der Speicherplatzgewinn im Verhältnis zur Codeverlangsamung auszahlt.

 

[Jennesta]

Hallo,

noch ein Anwendungsbeispiel aus meinem Arbeitsumfeld. Ich persönlich finde es zur Speicheroptimierung sehr wichtig, zumindest über solche Lösungen einmal nachzudenken. Nicht selten haben Leute hier zu Testzwecken unoptimierte Programme geschrieben und wollen dann an Großrechner, weil eben die Speichergrenze vom eigenen PC überschritten ist. Da würde z.B ein von dir genannter Faktor von 1:2 sehr viel ausmachen indem man das Byte doppelt nimmt.

Eine andere Möglichkeit besteht noch darin die Stärken einzelner Programme und Prozesse zu nutzen. Einige können z.B. besonders schnell double-Werte (64bit) verarbeiten. In diesen kann man sehr einfach auch ints "verstecken" und die einzelnen Bytes dann zu ints casten. Wobei sich das natürlich hauptsächlich lohnt, wenn die Werte sowieso gemischt vorkommen.

Ansonsten ist meine Empfehlung immer den kleinsten Datentyp zu nutzen wie nötig. Z.B. short statt int, float statt double usw. Auch diverse Flags kann man statt einzelnen bool-Variablen in eine zusammenfassen (auch wenn letzteres jetzt nicht das Optimierungskriterium an erster Stelle wäre).

Grüße,
Jennesta

 

[Caligulaminus]

Du hast aber mehrere Programme, die auch Ram brauchen...

Es ging konkret um 5.000.000 Byte, nicht um mehrere ominöse Programme die natürlich auch Speicher brauchen.
Die Angabe "20% Ersparnis" hat ohne konkretre Bezugsgröße einfach keine Aussagekraft in Bezug darauf, ob sich etwas lohnt.
Zählen tun die Umstände(z.B. Plattform) und die Vor- und Nachteile des vorgeschlagenen Verfahrens im Vergleich zu anderen Möglichkeiten, ein konkretes Problem zu lösen.
Auf meinem PIC-Messverstärker mit ingesamt 6MB RAM könnte sich das angesprochene Verfahren auszahlen. Aber wieder abhängig von ganz konkret zu nennenden Umständen.

Einfach nur 20% von irgendetwas zu sparen, weil es eben geht ist i.d.R. Unsinn.

Die Frage war: "Lohnt es sich?" und meine Antwort war: "Kommt drauf an."

 

[ComFreek]

Hallo!

ich möchte hier nur folgenden Satz einwerfen:

Probieren geht über Studieren

Schreib doch also einen kleinen Benchmark.

Übrigens macht es manchmal auch einen Unterschied, welchen Compiler man verwendet. Der Intel Compiler kann beispielsweise Code speziell für Intelprozessoren optimieren!

ich kann mich sehr über SW aufregen, die langsamer ist, als ich tippen/klicken kann.

Oh ja! Oder wenn der PC langsamer scrollt, als ich am Mausrad drehen kann!

 

[cwriter]

Erstmal vielen Dank für die vielen Antworten!

@sheel

Bitte nicht, das stimmt genau so wenig wie vor 30 Jahren.
Die HW ird immer stärker, aber die SW braucht auch immer mehr Platz und Leistung
für die selben Sachen. Eben weil sich keiner mehr die Mühe macht, auf Effizienz zu achten.

Natürlich. Ich schreibe zwar schlecht (auch wenn ich mich bessere), doch ich gebe mir keine Mühe, möglichst viel Speicher zu nutzen
Die Frage, die es interessant macht, ist: Lohnt es sich, pet Shift-Operator den Speicherhunger zu reduzieren und dafür mit der CPU zu heizen und bei der Ausführung zur besseren Verarbeitung temporär Speicher zu brauchen?

@Jennesta
Danke für die interessanten Ausführungen!

Ansonsten ist meine Empfehlung immer den kleinsten Datentyp zu nutzen wie nötig.

Das würde ich auch so machen
Die Frage ist nur: Was mache ich, wenn es keinen kleineren Datentypen mehr gibt? Lohnt sich die Teilung oder bremst man das System damit zu stark?

Gruss
cwriter