Laden...

Macht Datenkompression immer Sinn?

Erstellt von Solix0x vor 4 Jahren Letzter Beitrag vor 4 Jahren 1.623 Views
S
Solix0x Themenstarter:in
12 Beiträge seit 2018
vor 4 Jahren
Macht Datenkompression immer Sinn?

Hallo, die Frage steht ganz unten, aber ich erkläre erstmal meinen Gedankengang.

Nehmen wir mal folgendes Beispiel:

Man sehe sich eine Anwendung an, die Nachrichten/Daten verschickt (sowas wie WhatsApp, ein Online-Spiel, was auch immer). Und nehmen wir mal eine Beispielnachricht mit "Hallo Welt". In der Uni habe ich gelernt, dass man das ganze in Nullen und Einsen kodieren kann und Redundanz entfernen kann, sodass die Anzahl der zu verschickenden Bytes kleiner wird, aber nicht der Informationsgehalt. Letztendlich habe ich eine Folge von sagen wir "1110011". Diese 8 Bits kann man jetzt wiederum als Zahl auffassen, in dem Fall ist es die Zahl 115 und 115 als Hexadezimalzahl ist 73.

Und allgemein würde ich nun sagen, dass je höher die Basis des Zahlensystems ist, desto weniger Ziffern braucht man, um die Zahl darzustellen. Sieht man ja auch, mit der Basis 2 sind es 8 Ziffern, bei 10 dann 3, und bei 16 2. Jetzt könnte ich ein Zahlensystem konstruieren, dass wie das Hexadezimalsystem auch Buchstaben als Ziffern verwendet.

Und wenn ich dann einen längeren Text als "Hallo Welt", sagen wir einen Text mit 200 Zeichen verschicken will, dann kann ich mein Verfahren wie oben beschrieben anwenden und könnte dann sowas wie "jfI0" rausbekommen mit einem Zahlensystem mit einer sehr hohen Basis und dann verschicke ich nur diese 4 Zeichen.

Beim Empfänger kommt das relativ schnell an, man vergleiche 4 zu 200 Zeichen. Jedoch muss der Empfänger das dann so dekodieren, dass er an die ursprüngliche Information kommt.

Also könnte man Datenmengen über das Internet stark reduzieren, aber wenn man mal schaut, dann brauchen die meisten Spiele doch eine Gigabyte um heruntergeladen zu werden. Hat meine Idee irgendeinen Haken, ist es so nicht umsetztbar oder was auch immer? Ich denke, dass nicht nur ich jemals diese Idee gehabt hat.

T
2.219 Beiträge seit 2008
vor 4 Jahren

Dein Ansatz hat mehr mit Datenkompression als Vershlüsselung zu tun.
Kodierung/Dekodierung passt nach deiner Beschreibung auch nur oberflächlich.
Besser wäre eben Kompression und Dekompression.

Dafür gibt es schon viele Varianten wie z.B. Zip oder xz, die auch abhängig von ihrem Einstellungen/Umsetzungen, auch unterschiedlich gut sind.

Hier muss man meistens zwischen CPU Last, Speicherverbrauch und Kompressionsrate unterscheiden.
Will man hohe Kompression erreichen, bedeutet dies hohe CPU Last und Speicherverbrauch.
Will man wenig CPU Last und Speicherverbrauch, dann muss man bei der Kompressionsrate Abstriche machen.

Datenkompression spielt bei einigen Spieleplatformen auch heute eine Rolle und ist auch entsprechend implementiert.
Hier werden die Daten sowohl Komprimiert als auch verschlüsselt übertragen und beim Empfänger entpackt sowie Entschlüsselt.

Nachtrag:
Spieledateien sind bereits stark komprimiert, weshalb dort kaum noch Datenmengen gespart werden können.
Würde man sämtliche Dateien eines aktuellen AAA-Titels unkomprimiert ausliefern, würde dies locker 1-2 größere Festplatten im TB Bereich füllen.
Hier sind vorallem Multimedia Dateien wie Musik/Sounds, 3D-Modelle und Texturen bereits durch ihre eigenen Formate vorkomprimiert.
Trotzdem müssen immer noch einige Gigabyte an Daten geladen werden.
Und dies eben obwohl diese schon stark komprimiert sind.
Du kannst dir mal anschauen was z.B. eine DVD oder Bluray Disc unkomprimiert an Daten fressen würde.
Da merkt man schon, dass heutige Verfahren schon unglaublich effizient aber auch sehr Hardware hungrig sind.

Du bist auch nicht der erste, der sich darüber gedanken macht.
Einige Protokolle zur Datenübertragung, sowohl im LAN als auch über das Internet, bieten eben über angebundene Kompressions Libs entsprechende build-in Kompression an.
Z.b. kann ich mit rsync Daten auch komprimiert über das Netz schieben und laden.
Nur hängt die Effizienz eben davon ab ob die Daten noch in der Rohform vorliegen oder durch ihr Format selbst schon komprimiert sind.

Eine 1GB Textdatei lässt sich locker auf 500MB oder weniger komprimieren.
Eine 1GB Zip Datei aber nur auf einige MB weniger, je nach Kompressionsverfahren, was angewendet wird.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

S
Solix0x Themenstarter:in
12 Beiträge seit 2018
vor 4 Jahren

Ah danke, ich habe erstmal den Titel vom Thema geändert 😃 Und sowas scheint dann doch nicht unüblich zu sein

T
2.219 Beiträge seit 2008
vor 4 Jahren

@Solix0x
Bitte lies auch meinen Nachtrag im Kommentar oben.
Unüblich wäre noch eine Untertreibung.
Kompression bei der Datenübertragung ist bei vielen Protokoll und Dateien möglich, aber eben nicht bei allen.
Es hängt eben auch von den Daten ab, ob man noch was komprimieren kann oder nicht.

Hier kannst du dich gerne weiter einlesen.
Wiki: Datenkompression

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

16.806 Beiträge seit 2008
vor 4 Jahren

Eine 1GB Textdatei lässt sich locker auf 500MB oder weniger komprimieren.
Eine 1GB Zip Datei aber nur auf einige MB weniger, je nach Kompressionsverfahren, was angewendet wird.

Das hinkt an der Stelle; a) weil ZIP bereits prinzipiell eine Kompression darstellt / darstellen kann und b) eine Kompression verschiedene Stufen hat.
Man kann zB ZIP Dateien ohne Kompression erstellen (Container only).

Man sehe sich eine Anwendung an, die Nachrichten/Daten verschickt (sowas wie WhatsApp, ein Online-Spiel, was auch immer).

Datenkompression ist immer CPU-lastig, weshalb man sich überlegen muss, ob Kompression sinn macht.
Gerade bei Apps vermeidet man deswegen Kompression, denn die Mehrlast kostet Akku und bekommt dann vom Betriebssystem ein schlechtes Ranking, weshalb die Leute dann Apps runter schmeissen.

Kompression baut man sehr selten direkt in Anwendungen ein; sondern sind eher Teil der Infrastruktur.
Kompression macht die Sache der Kommunikation auch nicht zwangsläufig schneller.

C
2.121 Beiträge seit 2010
vor 4 Jahren

Ich möchte auf diese Aussage eingehen, denn ich habe das Gefühl die ist das Verständnisproblem in diesem Beitrag.

Und wenn ich dann einen längeren Text als "Hallo Welt", sagen wir einen Text mit 200 Zeichen verschicken will, dann kann ich mein Verfahren wie oben beschrieben anwenden und könnte dann sowas wie "jfI0" rausbekommen mit einem Zahlensystem mit einer sehr hohen Basis und dann verschicke ich nur diese 4 Zeichen.

Sagen wir du hast eine 4 stellige Zahl im Hexsystem und betrachtest die jetzt als 2 Bytes im "Byte System".
In deiner Aussage verwendest du den Begriff "Zeichen" verschieden. In meinem Beispiel wäre das einmal "4 Zeichen Hex" und "2 Zeichen als Byte". Du siehst hier den Vorteil dass du aus vier Zeichen zwei machen kannst. Es handelt sich aber nicht um den selben Zeichenvorrat!
Du musst nämlich auch berücksichtigen dass ein Byte doppelt so breit ist wie eine Hexziffer.
Es gibt 16 Hexziffern, aber 256 Byteziffern. 4 Hexziffern brauchen 4 x 4 Bit, die 2 Bytes brauchen 2 x 8 Bit. Also nichts gespart.
Die Sichtweise mit dem höheren Zahlensystem ist also rein gedanklich. Du hast 16 Bits und betrachtest die einmal als vier Hexziffern und das andere mal als zwei Bytes. Aber es bleiben trotzdem 16 Bit.

In deinem Beispiel schreibst du umgerechnet, du stellst einen Text mit 50 Zeichen durch ein einziges Zeichen dar. Auch hier ist Zeichen nicht gleich Zeichen.
Sagen der Text besteht aus 50 Bytes, also jede Stelle im Text kann 256 Möglichkeiten annehmen. Das ist der Zeichenvorrat "Typ A".
50 solche Bytes hintereinander ergeben 25650 Möglichkeiten für den Text. (Zur Vorstellung, das ist eine Zahl mit 121 Stellen)
Dein Zeichenvorrat "Typ B", bei dem du für den Text nur ein einziges Zeichen brauchst, müsste also 256
50 verschiedene "Typ B Ziffern" enthalten.
Das heißt du hast dann gedanklich zwar nur eine einzige "Typ B Ziffer", aber um diese eine Ziffer eindeutig darzustellen wäre sie in Bits betrachtet wiederum so breit dass du den selben Platz brauchst.

709 Beiträge seit 2008
vor 4 Jahren

Diese Folge des RFC-Podcasts erklärt Deflate ganz gut.
Daran kann man bei einem Verfahren also schon mal gucken, wie das dort gemacht wird.