Verteilte GPU-beschleunigte Datenkompression

Radeon HD 5870

Neuling
Thread Starter
Mitglied seit
19.02.2010
Beiträge
44
Ort
Bangor
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?
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Hört sich Klasse an. Denke aber das die Zeit die man zum Hochladen braucht, länger dauert als wenn man es selbst zippt.

Grüße
 
Erstmal interessantes Projekt und ohne es schlecht machen zu wollen, sehe ich den Durchschnittlichen Upload in DE auch als Problem. Das ganze lohnt sich in der Regel erst bei großen Dateien und bis Otto normal Bürger diese hochgeladen hat mit <1Mbit/s vergehen Stunden. Da kann man das auch gleich selber machen. Bei großen Firmen wie PCG, CNET, ... sieht das dann anders aus, die dürften auch noch etwas Geld sparen, da weniger Traffic verursacht wird. die Frage ist aber lohnt es sich für den Kunden? Wie lange dauert das Entpacken im vergleich zu der gesparten Zeit beim Download? (Kosten/Nutzen)

Eine Alternative wäre es, dem Server die URL zukommen zu lassen und der lädt dann automatisch runter, komprimiert und schickt die Datei weiter. Dann könnte es aber rechtliche Probleme geben, wenn illegale Daten komprimiert werden, da der Server/dessen Betreiber dann der Verteiler ist.
 
Hört sich Klasse an. Denke aber das die Zeit die man zum Hochladen braucht, länger dauert als wenn man es selbst zippt.

Grüße

Aktuell betraegt die Komprimierungsrate auf einer Radeon HD 7950 4KB/s.

Erstmal interessantes Projekt und ohne es schlecht machen zu wollen, sehe ich den Durchschnittlichen Upload in DE auch als Problem. Das ganze lohnt sich in der Regel erst bei großen Dateien und bis Otto normal Bürger diese hochgeladen hat mit <1Mbit/s vergehen Stunden. Da kann man das auch gleich selber machen. Bei großen Firmen wie PCG, CNET, ... sieht das dann anders aus, die dürften auch noch etwas Geld sparen, da weniger Traffic verursacht wird. die Frage ist aber lohnt es sich für den Kunden? Wie lange dauert das Entpacken im vergleich zu der gesparten Zeit beim Download? (Kosten/Nutzen)

Die dekomprimierungsrate soll sehr schnell sein selbst auf lahmen Prozessoren wie z.b. ARM.

Eine Alternative wäre es, dem Server die URL zukommen zu lassen und der lädt dann automatisch runter, komprimiert und schickt die Datei weiter. Dann könnte es aber rechtliche Probleme geben, wenn illegale Daten komprimiert werden, da der Server/dessen Betreiber dann der Verteiler ist.

Optimaler waere es wenn der Betreiber der Download Webseite die Datei bereits mit dem verfahren komprimiert haette.
 
-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)

Hierzu hätte ich ein paar Fragen... denn aus meiner Sicht, ist das ein leichter Widerspruch!

Du sagst einerseits, die Datenkompression wird erhöht, was für gewöhnlich gleichsam einher geht, mit höherer Zeit für das Komprimieren bzw. Dekomprimieren.
Und andererseits, der Vorteil beim Endkunden mit "lahmer" INet Leistung... Sicher spart er minimal (oder eben mehr, je nach absoluter Größe) Zeit beim reinen Download. Aber er spart wohl definitiv keine Zeit absolut, bis er die Daten auch verfügbar hat. Leider hilft ihm an der Stelle auch das verteilte Berechnen auf mehreren Computern nicht. Denn es erzeugt Aufwand, der idR nicht tollerierbar ist. (sofern es überhaupt andere PCs zum Nutzen gibt)

Den Ansatz mit dem verteilten Berechnen über das INet ist auch nicht so trivial, wie es den Anschein hat. Denn entweder er lädt die gepackten Daten auf seinen Client und lässt auch dort entpacken -> wohl hohe Zeit benötigt.
Oder er nutzt eben Rechenpower aus dem INet von anderen Personen. hat aber gleichsam den Nachteil, das er dann eben die Rohdaten über seine Leitung übertragen müsste... Eben das, was ausgepackt wurde...

Oder versteh ich nur den Ansatz nicht!?

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.

Um was für Daten handelte es sich?
Es lassen sich ja nicht alle Daten gleich stark/gut komprimieren...
Simples Beispiel: ein JPG Bild lässt sich via bekannten Programmen weit aus schlechter Komprimieren als ein BMP Bild oder vielleicht ne simple Textdatei. (in Relation zwischen vor dem Packen und nach dem Packen)
Oder ne MP3 gegen ein WAV File usw.

Zum anderen, wie steht es denn um den Rechengeschwindigkeit in Relation zur aufgebrachten Rechenpower?
ich mein, eine HD7950 hat enorme Rohpower im Vergleich zu ner simplen CPU. Es ist also bei halbwegs brauchbarer Implementierung fast schon logisch, das der Speed steigt bzw. eben die rein benötigte Zeit sinkt. Nur muss das idR in Relation gesehen werden. Mir persönlich nutzen 10% gesparte Zeit nix, wenn ich dafür die Grafikkarte auf Volllast fahren muss bzw. sogar mehrere davon brauche... ;)
 
Hierzu hätte ich ein paar Fragen... denn aus meiner Sicht, ist das ein leichter Widerspruch!

Du sagst einerseits, die Datenkompression wird erhöht, was für gewöhnlich gleichsam einher geht, mit höherer Zeit für das Komprimieren bzw. Dekomprimieren.
Und andererseits, der Vorteil beim Endkunden mit "lahmer" INet Leistung... Sicher spart er minimal (oder eben mehr, je nach absoluter Größe) Zeit beim reinen Download. Aber er spart wohl definitiv keine Zeit absolut, bis er die Daten auch verfügbar hat. Leider hilft ihm an der Stelle auch das verteilte Berechnen auf mehreren Computern nicht. Denn es erzeugt Aufwand, der idR nicht tollerierbar ist. (sofern es überhaupt andere PCs zum Nutzen gibt)

Die Dekompressionsgeschwindigkeit soll sehr hoch sein. Selbt auf einem lahmen ARM Prozessor soll die dekompressionsgeschwindigkeit akzeptabel sein (10MB/s). Mit einem Core i7-4770K sollten problemlos mehr als 100MB/s dekompressionsgeschwindigkeit drin sein.

Den Ansatz mit dem verteilten Berechnen über das INet ist auch nicht so trivial, wie es den Anschein hat. Denn entweder er lädt die gepackten Daten auf seinen Client und lässt auch dort entpacken -> wohl hohe Zeit benötigt.
Oder er nutzt eben Rechenpower aus dem INet von anderen Personen. hat aber gleichsam den Nachteil, das er dann eben die Rohdaten über seine Leitung übertragen müsste... Eben das, was ausgepackt wurde...

Oder versteh ich nur den Ansatz nicht!?

Er muss nicht mal den Client installiert haben um Daten entpacken zu koennen. Dazu wuerde er einen seperaten entpacker nutzen und selbst auf lahmen Systemen sollte die entpackungs geschwindigkeit sehr hoch sein.

Um was für Daten handelte es sich?
Es lassen sich ja nicht alle Daten gleich stark/gut komprimieren...
Simples Beispiel: ein JPG Bild lässt sich via bekannten Programmen weit aus schlechter Komprimieren als ein BMP Bild oder vielleicht ne simple Textdatei. (in Relation zwischen vor dem Packen und nach dem Packen)
Oder ne MP3 gegen ein WAV File usw.

Es handelte sich um die 100MB grosse enwik8 Textdatei.

Zum anderen, wie steht es denn um den Rechengeschwindigkeit in Relation zur aufgebrachten Rechenpower?
ich mein, eine HD7950 hat enorme Rohpower im Vergleich zu ner simplen CPU. Es ist also bei halbwegs brauchbarer Implementierung fast schon logisch, das der Speed steigt bzw. eben die rein benötigte Zeit sinkt. Nur muss das idR in Relation gesehen werden. Mir persönlich nutzen 10% gesparte Zeit nix, wenn ich dafür die Grafikkarte auf Volllast fahren muss bzw. sogar mehrere davon brauche... ;)

Die Radeon HD 7950 hat 8 Stunden gebraucht um die 100MB enwik8 Datei auf 35MB zu bekommen. Allerdings wurde nur ein Kompressionsverfahren benutzt, sobald mehr implementiert sind sollte winrar mit etwas Abstand geschlagen werden.
 
Das heist dann, das packen selbst dauert ewig, wärend das Entpacken sehr sehr fix ist!?
 
ich hab die von dir erwähnte textdatei eben mal spaßeshalber mit 7zip innerhalb von nichtmal 2 minuten gepackt - 23mb

selbst bei noch so guter implementierung werden da keine großartigen quantensprünge drin sein...

daher seh ich da irgendwie nicht den mehrwert, wenn man bei riesigen dateien vielleicht mal 200mb spart (in abhängig davon wie gut packbar die sind), dafür aber 3 tage zum packen braucht und hier unverhältnismäßig viel aufwand für unverhältnismäßig wenig mehrwert betreibt... sorry, aber meine meinung ;)
 
Zuletzt bearbeitet:
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh