Komprimierbarkeit von Software (OS+Programme)

[jusaca]

Die SF-Controller komprimieren die Daten ja, um Geschwindigkeit und Lebensdauer zu erhöhen.
Nun weiß jeder, dass ein bereits komprimiertes .rar-Archiv kaum weiter eingestampft werden kann, während ein wave-file oder ein .doc mal locker in der Größe halbiert werden kann.

Aber wie sieht das mit den Daten von typischer Software aus?
Liegen die ganzen Dateien bereits stark komprimiert im Verzeichnis, sodass der SF-Controller da nicht mehr viel rausholt, oder ist das alles relativ unkomprimiert abgelegt, um die CPU zu entlasten?
Hauptsächlich würde mich das für das OS (Win 7) und so typischen Programmen wie Office, Browser, Messanger, Photoshop, ... interessieren

Grüße
jusaca

 

[the_nobs]

selber testen

nimm den windows ordern und kompremier ihn mal mit Winzip/7z/Rar oder was auch immer
Das sind zwar andere Algorithmen aber grundsätzlich vergleichen lassen sie sich sicher!


mfg Norbert

 

[Quackmoor]

"Die Dateien von Windows sind etwa so stark komprimierbar, dass sie auf eine Installations-DVD passen." - Der gesunde Menschenverstand

 

[Kiviuq]

Ich hab keinen SF-Controller, sondern die C300 mit Marvell-Controller, so dass ich zu der SSD-Komprimierung selbst nichts sagen kann. Zur allgemeinen Komprimierbarkeit jedoch:

Systemplatte (OS (Win7), Programme, keine Mediendaten): 42,5GB belegt von 119GB
Backup-Zip (inkl. 100MB-Systempartition): 15,18GB

// Edit: Hab übrigens nicht die allerhöchste Kompression eingestellt. Backup ist mit Acronis TrueImage 2011 erstellt.

 

[eightcore]

Ich habe vor kurzem das Hauptverzeichnis von GTA IV komprimiert. Dazu habe ich WinRAR 3.90 benutzt und die höchste Komprimierungsstufe eingegstellt. Das Verzeichnis war etwa 15 GB gross, das Archiv 13 oder 14 GB.

Ist also nicht so viel rauszuholen, zumindest in meinem Fall.

 

[Blublah]

etwa 30% für Programme.
MS Office z.B. von 460MB auf 330MB mit Windows Ordnerkomprimierung.

Wav Dateien lassen sich übrigens mit 'normaler' Komprimierung fast gar nicht komprimieren. Nur spezielle Algorithmen welche quasi 'akustische' (und nicht binaere) Komprimierung vornehmen koennen wav Dateien verkleinern. Nur sind das dann keine wav Dateien mehr und je nach Komprimierungsstufe kostet das auch entsprechend Tonqualitaet.

Bei Spielen, welche ja oft sehr viel Platz beanspruchen, ist normalerweise noch weniger rauszuholen, eher 5 - 20% max. Das liegt daran, dass die groessten Speicherplatzfresser wie Videos/Musik/Texturen schon vorkomprimiert sind.

 

[Holt]

Leute, ich vergleich hier eine CPU mit bis zu 130Watt Leistungsaufnahme und einigen GB RAM mit einem SF Controller, der für alles, also NAND und SATA Ansteuerung, Datenverwaltung nur 900mW (SF22xx: 1.5W) für seine zwei Cors zur Verfügung hat und nicht einmal über externes RAM verfügt. Wieviel RAM hat der wohl intern? Kaum so viel wie die CPU an Cache hat und dann braucht die CPU zum komprimieren auch nich recht lange und der SF muß das alles in Echtzeit, also auf einem Datenstream von mehreren 100MB/s machen. Wenn der die Kompressionsraten erreicht, die an die der NTFS Datenkompression herankommen, dann macht der eine super tolle Arbeit mit seinen bescheidenen Möglichkeiten.
Der Kompressionstest von ASS zeigt ja auch, dass die 50% komprimierbaren Daten längst nicht doppelt so schnell geschrieben werden wie die nicht komprimierbaren, weil der diese Daten vermutlich eben längst nicht auf die Hälfte komprimiert bekommt. Mit 7zip kann man ja verschiedene Studfen einstellen und dann kann ja jeder mal vergleichen, wieviel Zeit man braucht um welche Kompressionsraten zu erzielen.

 

[Blublah]

Ist klar, dass der Sandforce Controller keinen so hohen Komprimierungsfaktor wie z.B. ein normales zip haben wird, da er die Daten sicher nur relativ lokal (im bereich von einigen Bytes) komprimiert und nicht die Zeit hat nach groesseren Mustern zu suchen. Allerdings sollte man auch nicht die Geschwindigkeit eines ASIC (application specific integrated circuit) unterschaetzen welcher gezielt fuer eine ganz bestimmte Aufgabe entwickelt wurde.

Irgendwie ärgerlich finde ich ja noch die (praktisch nicht änderbare) Tatsache, dass der durch die Komprimierung eingesparte Platz auf der SSD nie nutzbar ist. Wenn man zu 100% wüsste, dass die Komprimierung über 30% liegen wird, könnte der Controller theoretisch eine 'virtuelle SSD' mit 30% mehr Platz zur Verfügung stellen.

 

[Holt]

Schaut doch einfach mal auf den Kompressionsbenchmark von ASS und vergleicht die Werte bei 50% mit der seq. Transferrate. Liegt die Schreibgeschwindigkeit dann doppelt so hoch?

 

[Holt]

So ungefähr sieht das dann aus.