Fiber Pool 1.0.0.7 steht nun zum Download zur Verfügung.
Nachdem der Performancevergleich meiner Inflate-Implementierung eher unbeachtet blieb, habe ich mich drangesetzt und den Deflate-Algorithmus zum Komprimieren ebenfalls integriert.
Wenn’s gut läuft, werde ich dieses Wochenende auf der Produkt-Homepage beschreiben, wie die Kompression mit Fiber Pool durchgeführt wird. Wenn ich’s nicht schaffe, wird das wohl erst nach Pfingsten…
Anmerkung am Rande: Der Kompressionsalgorithmus ‘Deflate’ wurde wie dazumal ‘Inflate’ nicht verändert!
Nun, die obligatorischen Benchmarktests:
Der Testrechner war wie folgt konfiguriert:
- Intel Q9450, Win Vista Home Premium 64-Bit, 8GiB RAM, kein Superfetch
- Laufwerk C: Samsung HD502IJ (SATA)
- Laufwerk E: Seagate ST31500341AS (SATA)
- Laufwerk F: Western Digital MyBook (USB)
Test 1: Komprimieren des “Microsoft SDK”-Ordners auf derselben Festplatte (Laufwerk C: 1,5 GiB/15.400 Dateien).
Komprimieren mit…
…fpzip x64: 244s
…7z 4.65 x64: 322s (7z a -tzip -r …)
…WinRAR 3.90 Beta 1 x64: 379s (winrar a -afzip -r …)
7z ist 32% langsamer, WinRAR um 55%.
Test 2: Komprimieren von MP3-Dateien auf derselben Festplatte (Laufwerk E: 1,95 GiB/286 Dateien).
Komprimieren mit…
…fpzip: 53s
…7z: 134s
…WinRAR: 157s
7z ist um 153% langsamer, WinRAR um 196%.
Test 3: Komprimieren von Bilddateien von F: nach E: (1,14 GiB/937 Dateien).
Komprimieren mit…
…fpzip: 57s/45s*
…7z: 59s
…WinRAR: 75s
* Im zweiten Versuch erhielt der File I/O Scheduler zwei Threads.
Während 7z gleichauf ist, ist WinRAR knapp 32% langsamer.
Test 4: Komprimieren des “Microsoft SDK” von C: nach E:.
Komprimieren mit…
…fpzip: 144s/140s*
…7z: 181s
…WinRAR: 183s
Hier sind beide Konkurrenten etwas mehr als 25% langsamer.
Test 5: Komprimieren von MP3-Dateien von E: nach C:.
Komprimieren mit…
…fpzip: 52s/49s*
…7z: 54s
…WinRAR: 135s
WinRAR ist um 160% langsamer.
Fazit:
WinRAR hat sich bei meinen Tests als lahme Ente erwiesen. Der Grund dafür liegt wohl hauptsächlich daran, dass der gesamte Vorgang auf einem Thread durchgeführt wird. Sein Übriges tut das synchrone I/O, das zum Lesen und Schreiben verwendet wird. Der Speicherverbrauch ist dabei natürlich minimal (um 30 MiB), aber wünscht man sich das, wenn man 8 GiB hat?
Wirklich schnell ist aber die Deflate-Implementierung: Auf einem schwächeren Testsystem mit einem HT-Prozessor war WinRAR der Schnellste – trotz (oder gerade wegen) eines Threads.
7z verwendet mehrere Threads und ist daher z.T. deutlich schneller als WinRAR. Was die Threads aber genau tun, habe ich noch nicht untersucht.
Anhand der Tests 2 und 5 erkennt man, dass die an sich sehr gute Bearbeitung der Dateien durch das synchrone I/O (Test 2) zunichte gemacht wird.
fpzip verwendet nicht nur mehrere Threads, sondern setzt auch dateiübergreifendes, asynchrones I/O ein. Hinzu kommen noch die Speichermanagement-Klassen, die die Speichernutzung kontrollieren.
Das Zusammenspiel zwischen Prozessorkernen, I/O und Speicher wird in Test 2 deutlich: Die Festplatte ist hier wegen der langwierigen Duplikatssuche schneller als der Kompressionsalgorithmus und kann daher asynchron mehrere Dateien in den Hauptspeicher laden. Die Folge ist, dass nun mehrere Kerne mit der Kompression von Dateien beschäftigt werden können.
Hinweis: Bei fpzip handelt es sich nur um eine Beispielanwendung, die in keinster Weise fehlerfrei ist und auch nicht die vollständige PKZIP-Spezifikation implementiert. Es gibt sicher noch einiges zu verbessern, denn das optimale Verhalten wird noch nicht erzielt. Wenn es jemanden gibt, der das weiterentwickeln möchte, der kann sich gerne bei mir melden.