Verteilte GPU-beschleunigte Datenkompression

[thysol]

Hi,

Hättet ihr Interesse an einem System mitzumachen das Daten komprimiert, die Rechenleistung auf mehrere Systeme verteilt, so ähnlich wie bei Folding@Home?

Ziele des Systems:

- Sehr hohe Datenkompression erreichen, besser als Winrar, 7z, etc.
- Sehr hohe dekomprimierungsraten erreichen, deutlich besser als winrar, 7z, etc. (>100MB/s sind angepeilt)

Dies soll erreicht werden indem Abstriche gemacht werden bei der Komprimierungszeit. Komprimierungen auf einem einzelnen Rechner könnten Stunden bis Tage dauern. Die hohen Performance Anforderungen sollen folgendermassen eingeschränkt werden:

- GPU-beschleunigung (bereits implementiert)
- Multi-GPU Unterstützung (bereits implementiert)
- Dynamische Last-Verteilung (bereits implementiert
- Verteiltes Rechnen über das Internet (ähnlich wie Folding@Home, BOINC, etc.)

Warum würde ein User da mitmachen wollen?

-Wenn der Privat Rechner vom User online ist und komprimiert werden dem User Punkte gutgeschrieben die er/sie später selber verwenden kann um Daten durch verteiltes Rechnen deutlich schneller komprimiert zu kriegen als würde sein eigener Rechner die Daten komprimieren.

-Wenn Downloads (PCGH Downloads, CNET Downloads, usw.) mit dem Verfahren komprimiert werden könnte die Datenkompression deutlich erhöht werden und gleichzeitig die Dekompressions Geschwindigkeit auch erhöht werden. Das würde Usern mit einer lahmen Internet Leitung zugute kommen. (Fette Patches oder so könnten deutlich schneller runtergeladen werden)

Letztes Wochenende habe ich einen Test auf einer Radeon HD 7950 durchgeführt, die Software, die noch in einer sehr frühen Entwicklungsphase ist, komprimierte eine 100MB Datei auf 35MB, Windows Zip erreicht in etwa das gleiche, winrar dagegen 28MB. Die Software ist aber noch in einer sehr frühen Phase, es soll noch mindestens ein anderes Kompressionsverfahren implementiert werden das mit dem bereits implementierten zusammen arbeitet um die grösse der komprimierten Dateien deutlich zu reduzieren. Bereits jetzt ist die dekomprimierungsgeschwindigkeit deutlich geringer als bei winrar.

Es funktioniert schon vieles, Multi-GPU beschleunigung, dynamische Last-Verteilung, etc.

Was jetzt als nächstes implementiert werden soll ist eine weitere Kompressionsmethode um die Dateien noch kleiner zu kriegen (das mit der ersten zusammen arbeitet), und worauf ich eigentlich hinaus will eine Server-Client Infrastruktur, wo ein Server die Last dynamisch auf die Clients verteilt (mit dynamischer Last-Verteilung). Die Clients hätten accounts auf dem Server und würden Punkte sammeln womit sie später Daten auf den Server hochladen können, die dann vom Server zur Komprimierung gescheduled werden, später komprimiert vom Server wieder runtergeladen werden können.

Das ist relativ viel Aufwand, allerdings soll die Belohnung sehr kleine Dateien sein die so schnell dekomprimiert werden können das die Festplatte/SSD limitiert.

Hättet ihr Interesse da mitzumachen?

 

[Astimon]

Ich glaube die Akzeptanz wäre bedeutend größer, wenn das Verfahren nur noch beschleunigt werden müsste, und es bereits überragende Komprimierungsraten (nur eben extrem langsam) erbringen würde. Ich denke nämlich das die vorhandenen Algorithmen schon ziemlich ausgereift sind.
Wie lang hast du und wie lange hat Winrar/Winzip denn gebraucht um die Datei zu komprimieren die du erwähnt hast?

Es sind ja auch keine unerheblichen Datenmengen die da durch die Internetleitung rasen sollen. Bei deinem Beispiel wär es mit einem zusätzlichen Rechner der dir hilft schon 67 MB bei 100 zu komprimierenden MB. Der Großteil sogar noch als lahmender Upload. Ich meine Dateien wo man diesen Aufwand betreiben würde, liegen im GB-Bereich.

Man würde durch das verteilte Rechnen nur Zeit sparen, aber der PC muss dennoch vom Stromverbrauch her die komplette Datei komprimieren, da alles was er nicht komprimiert durch das Punktesystem (finde ich übrigens eine sehr faire Möglichkeit) für andere Leute zu anderen Zeitpunkten berechnet werden muss. Außer Zeitersparnis sehe ich keinen großen Vorteil für das aufwendige Verfahren.

Sorry das ich die Idee etwas kaputt mache - aber ich sehe hier keine Zukunft für das Projekt.

 

[Incredible Alk]

Ich sehe das gleiche Problem wie Astimon - ein solches System bei parallelen Rechnern setzt eine sehr große Bandbreite der Kommunikation voraus, da nicht wie bei Folding@home sehr viel Rechenzeit auf sehr wenig Datenmenge kommt sondern die Datenmenge bei Komprimierungen sehr hoch ist (sonst lohnts sich ja nicht) - und die müssen nunmal alle durch die Leitung.

Schön und gut wenn dein Cluster >100MB/s komprimieren kann aber wer hat denn bitte eine Internetleitung zu Hause die 800 MBit Upload bietet?

Zumindest im privaten Bereich sehe ich auch zu wenig Workload für ein solches System - ich denke nicht dass es viele Leute gibt die ständig GB-weise Daten komprimieren müssen (und alles was darunter liegt kann man in akzeptabler Zeit auf einem einigermaßen neuen PC zu Hause selbst erledigen).

Für Server könnte es interessant werden da diese den Workload UND die Bandbreite zur Verfügung haben könnten - ich würde aber nicht erwarten dass sich an dem System irgendwelche Privatpersonen beteiligen.


Nebenbei erwähnt: Wenn ihr ein Kompressionsverfahren entwickelt das besser komprimiert als LZMA von 7zip und sehr viele Threads auslasten kann wäre mir die erforderliche Rechenzeit beinahe egal (Zeit ist extrem selten der beschränkende Faktor wenn ich was komprimieren will) - da würde ich mich aber tief verneigen vor der Entwicklungsleistung da LZMA bereits ein sehr ausgeklügeltes und mächtiges Datenkompressionsverfahren ist. (Sollte euch das tatsächlich gelingen braucht vermutlich auch niemand von euch mehr arbeiten zu gehen wenn mans geschickt verkauft )

 

[thysol]

Wie lang hast du und wie lange hat Winrar/Winzip denn gebraucht um die Datei zu komprimieren die du erwähnt hast?

Winrar: 15-30 Sekunden
Eigenes Programm: 7-9 Stunden

Es sind ja auch keine unerheblichen Datenmengen die da durch die Internetleitung rasen sollen. Bei deinem Beispiel wär es mit einem zusätzlichen Rechner der dir hilft schon 67 MB bei 100 zu komprimierenden MB. Der Großteil sogar noch als lahmender Upload. Ich meine Dateien wo man diesen Aufwand betreiben würde, liegen im GB-Bereich.

Nicht jeder Client wird die ganze Datei herunterladen muessen. Der Server soll in der Lage sein die Internetgeschwindigkeit von den verschiedenen Usern zu testen und dann entscheiden welche User mehr Daten bekommen. Was den Upload betrifft, eine Radeon HD 7950 wuerde mit der aktuellen Version ca. 4KB/s Upload verursachen. Upload ist also kein Problem.

Man würde durch das verteilte Rechnen nur Zeit sparen, aber der PC muss dennoch vom Stromverbrauch her die komplette Datei komprimieren, da alles was er nicht komprimiert durch das Punktesystem (finde ich übrigens eine sehr faire Möglichkeit) für andere Leute zu anderen Zeitpunkten berechnet werden muss. Außer Zeitersparnis sehe ich keinen großen Vorteil für das aufwendige Verfahren.

Hoho dekompressionsraten + bessere Kompression.

Schön und gut wenn dein Cluster >100MB/s komprimieren kann aber wer hat denn bitte eine Internetleitung zu Hause die 800 MBit Upload bietet?

Der Upload wird bei Privaten Anschluessen einige Zeit beanspruchen, allerdings wird es immer noch viel schneller sein als wenn mann die Datei zu Hause komprimiert. Eine Radeon HD 7950 braucht aktuell ca. 8 Stunden um eine 100MB Datei zu komprimieren. Die Kompressionsgeschwindigkeit nimmt exponentiell ab je groesser die Datei wird. Wenn mann mehrere GB an Daten auf einer Radeon HD 7950 komprimieren wollte wuerde es vermutlich Tage dauern.

Zumindest im privaten Bereich sehe ich auch zu wenig Workload für ein solches System - ich denke nicht dass es viele Leute gibt die ständig GB-weise Daten komprimieren müssen (und alles was darunter liegt kann man in akzeptabler Zeit auf einem einigermaßen neuen PC zu Hause selbst erledigen).

Da hast du Recht, das System wuerde sich erst ab ca. 100MB Dateien lohnen.

Nebenbei erwähnt: Wenn ihr ein Kompressionsverfahren entwickelt das besser komprimiert als LZMA von 7zip und sehr viele Threads auslasten kann wäre mir die erforderliche Rechenzeit beinahe egal (Zeit ist extrem selten der beschränkende Faktor wenn ich was komprimieren will) - da würde ich mich aber tief verneigen vor der Entwicklungsleistung da LZMA bereits ein sehr ausgeklügeltes und mächtiges Datenkompressionsverfahren ist. (Sollte euch das tatsächlich gelingen braucht vermutlich auch niemand von euch mehr arbeiten zu gehen wenn mans geschickt verkauft )

Momentan habe ich leider keine Ahnung wie stark das System komprimieren koennen wird. Das einzige was klar ist, je groesser die Datei, desto besser wird die Komprimierung und desto geringer sollte der Abstand zu LZMA werden, aktuell ist 100MB die groesste Datei die mit dem System komprimiert wurde. Was auch noch klar ist, der Entropy Coder wird die komprimierung verbessern, nur um wie viel kann mann nur raten. Momentan ist das Projekt nicht kommerziell orientiert und aktuell ein ein Mann Projekt.