Verteilte GPU-beschleunigte Datenkompression

[Ohne Gehäuse]

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?

 

[DefconDev]

Jap, ich hätte ein riesiges Interesse daran! Welche Aufnahmekriterien muss ich haben?

Ich habe nen Phenom x4+GTX460 ohne SSD.

 

[Visceroid]

Du denkst also ein Kompressionsverfahren zu entwicklen dass noch um Ecken besser ist als 7zip/WinRAR und co?
Da sich die ganzen Top Programme gerade mal ein paar % Kompressionsunterschied geben bin ich doch sehr gespannt wie du das erreichen willst.
Das verteilte Komprimieren/Dekomprimieren hört sich ja gut an, aber ist wohl erst bei großen Datenmengen sinnvoll wo ein einzelner PC ewig brauchen würde und da wird bei den meisten dann die Internetleitung wohl nicht mitspielen?!

Abgesehen davon in der Zeit der No-Limit Internetzugänge ist auch die Datenmenge nicht mehr relevant.
Vielleicht verstehe ich es falsch, aber selbst wenn du es schaffst einen 200MB Grafiktreiber auf 180MB zu verkleinern, muss dann für die Dekompression (welche aktuell innerhalb von 5 Sekunden fertig ist) wieder Daten hin und her geschickt werden und würde deiner Meinung nach wie lange dauern?

Abgesehen davon, beim Enduser anzufangen ist wohl der falsche Ansatz? Die komprimierten Dateien müssten wohl auf den Anbieter Servern liegen?
Ich denke nicht dass viele User gewillt sind ihre neuen Grafiktreiber von www.bittegibmirviren.de runterzuladen?

 

[Radde]

Ich verstehe das Prinzip noch nicht ganz.
Die Daten werden auf verschiedenen Rechnern übers Netz verteilt komprimiert/dekomprimiert. Das dadurch viel mehr Rechenpower vorhanden ist um die Dateien deutlich kleiner zu packen leuchtet mir noch ein.
Aber irgendwann muss dann doch die fertig entpackte Datei auf dem Rechner ankommen, der sie ursprünglich angefordert hat (z. B. einen PCGH Download). In dem Fall hilft es mir doch nicht, wenn die Datei superkleine .zip (so nenn ich sie der einfach mal) vom PCGH-Server "in die Cloud" geladen wird, dort entpackt wird um dann als riesige .exe auf meinem Rechner gespeichert zu werden. In diesem Fall muss ich ja doch den gesamten Download machen.

Wäre schön, wenn du darauf nochmal eingehen könntest. Danke!

 

[Uwe F.]

Ich fasse das mal zusammen:
Erst muß ich Ewigkeiten warten, bis meine Dateien komprimiert sind, denn der begrenzende Faktor ist ja wohl die Bandbreite meines Internetanschlusses, und zwar der Upload.
Dann muß ich den Strom für andere bezahlen, um Punkte zu sammeln, damit ich überhaut mal was komprimieren kann.
Derzeit ist noch keine Leistungssteigerung gegenüber den gängigen Packern zu erkennen.


Also ich habe für sowas keinen Bedarf.
Außerdem dürfte es wohl auch nicht mehr lange dauern, bis GPGPU bei den Packprogrammen Einzug hält.

 

[ynfinity]

Ich hab das so verstanden, dass wenn ich jetzt einen DL von PCGH oder wo auch immer machen möchte, über eine Clientsoftware ala Downloadmanager die Datei jeweils stückchenweise von allen aktuell verfügbaren Clientrechnern geladen wird, dann jeweils komprimiert wird und an mich gesendet wird (alles andere macht in meinen Augen keinen, bzw. noch weniger Sinn).
Das mit dem noch kleiner Komprimieren halte ich allerdings für nicht umsetzbar, 7zip, WinRAR und ZIP werden schon sehr nah am aktuell möglichen dran sein, und auch weiter forschen.
Das meiner Meinung nach beste ist die GPU zum komprimieren heranzuziehen. Das würde als einfaches Packprogramm sicherlich erfolgreich sein können.

 

[Sebbi]

1. solange wie es noch keinen Allumfassenden 1 Gbit/s Anschluss Symetrisch gibt für Privatleute im Bezahlbaren Rahmen gibt, is deine Idee Müll.

2.

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

ähm nur so zur info ... auf meinen i7 - 2600 schaff ich das bereits ohne deine tolle Idee auf meiner SSD

3. Datensicherheit

4.

-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)

ähm nein, da die idr schon gepackt sind, lassen die sich kaum noch mehr packen. Aufwand / Nutzen ungenügend

5.

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.

LOL damit disqualifiziert das teil sich schon selber .... vorallem mit dem Letzten Satz. Und WinRAR benutzt nun schon nur die CPU

6.

Außerdem zu Punkt 2. Was Soll das für nen Sinn haben, wieder online zu dekomprimieren? Dann müssen die Daten ja 2 Geladen und einmal hochgeladen werden. Einmal komprimiert, dann hochladen zum dekomprimieren und einmal dekomprimiert untergeladen (und wieder schön groß)

 

[Hito]

Nehmen wir an du kriegst das hin - WER SOLL DIESE DATEN DENN DEKOMPRIMIEREN?! Nur Leute mit eigener ServerFarm???!?!?!??!



......totaler Bloedsinn

 

[zEtTlAh]

Ähm... es ist ja nicht so, dass ich einige Sachen nicht verstehe sondern es ist so, dass ich das von vorne bis hinten nicht verstehe.

Erklär mir mal bitte eins:

Was ist so schwer daran, eine 100 MB Datei und 25MB zu bekommen ? Wenn du magst bau ich dir eine 1GB Text Datei und mach die kleiner als 25MB. Der Durchsatz wird dann auch weit über 100MB/s sein.

Online ist in Xfacher Hinsicht kompletter quatsch... Dazu muss eine Datei xmal hoch und runter oder zwischen Rechner hin und her verschickt werden. Das macht unterm Strich mehr Traffic als wenn ich die bereits gehostete Datei einfach runterlade und gut ist.

Kann es sein, dass heute der 1. April ist und es keiner gemerkt hat ?

Das einzige was ich hier interessant finde ich CUDA (o.Ä.) mit ins Boot zu nehmen und wenn du das getan hättest, dann hättest du das patentieren sollen und Kohle scheffeln. Kannst du aber nicht mehr da du bereits davon erzählt hast. Schade mit den Gesetzen. Wenn du mich fragst hast du garnichts.

 

[zEtTlAh]

Weisste was ? Ich mach mit, einfach nur, weil ich das sehen will. Voraussetzungen dazu hat mein System ja. Ich steck auch gerne noch 3 Quadro Karten dazu, die ideln hier eh nur rum. Dann kannst du gleich noch Multi GPU implementieren.

 

[Visceroid]

@Hades85: Wer redet was schlecht? Wir wollen einfach den Sinn dahinter verstehen, wenn die Idee jemals was bringen soll muss es wohl auch nur im geringsten einen Sinn haben. Wenn der Traffic dadurch aber höher wird hat es 0 Sinn, wenn ich auf meine entpackten Dateien warten muss hat es 0 Sinn, wenn es von niemanden Unterstützt wird weil zu unsicher/kompliziert hat es 0 Sinn.

Vielleicht verstehen wir ja auch alle sein Anliegen falsch, aber schlecht reden tut niemand wirklich was. Bis jetzt habe ich mehr oder minder sinnvolle Hinterfragung bzw. Kritik gelesen.

Das Kommentar von Dr.Duschlampe war wohl eher auf die "ich bin bereit alles zu testen" Einstellung von dir gedacht - würdest du also auch ein Programm testen welches nur 2 GB deines RAM verbraucht aber nicht wirklich einen Sinn hat?
Bevor ich ein Programm teste muss ich wissen was es tut, ob es MIR was bringt und welche Risken ich dabei eingehe.
Da ich nicht annehme dass man zum Programm auch den Source erhalten wird, bleibt es für mich ein Tabu, weil einen Keylogger einzubauen ist eine Kleinigkeit und ein Distributed Networking Programm wirst du in der Firewall eher nicht blocken

Nicht falsch verstehen, ich würde ein Program auch testen wenn es mir nichts bringt, rein um zu helfen, aber einfach jedes Programm runterzuladen und zu testen ohne etwas zu hinterfragen wird nicht passieren.

 

[Radde]

Das mit dem noch kleiner Komprimieren halte ich allerdings für nicht umsetzbar, 7zip, WinRAR und ZIP werden schon sehr nah am aktuell möglichen dran sein, und auch weiter forschen.

Vor nicht allzu langer Zeit (Feb 2013) gab es auf Tomshardware.de einen Test von 4 Packprogrammen. Die Ergebnisse der einzelnen Programme liegen weiter auseinander als ich das erwartet hätte. Es gibt also offensichtlich schon noch Optimierungsbedarf. Ich finde es auch sehr spannend, dass 7zip bei der .zip-Erstellung schneller und besser ist als winzip
Ich kann mir also schon vorstellen, dass es sinnvoll ist sich mit Komprimierung zu beschäftigen. Die Frage ist, ob der Cloud-Ansatz der praktikabelste ist?!

 

[Merlin-.-]

Also wenn das System lauffähig ist, dann hast Du krasses Know-How im Server-Client-Bereich und im GPGPU-Bereich gesammelt. Und damit kannst Du interessante andere Projekte umsetzen und erfolgreich damit sein.

Von diesem speziellen Vorhaben halte ich nicht viel, weil erstens Komprimieren zeiteffizient lösbar ist mit ner stinknormalen CPU und zweitens wird das Verhältnis aus Dateigröße/Rechenzeit unendlich schlecht und die Dateigröße kaum noch kleiner bei höherer Kompression.

Klarer Nachteil bei "besserer" Kompression sind z.B. auch die solid blocks. Das führt dazu, dass Deine gesamte Datei kaputt ist, sobald sie einen kleinen Fehler enthält. Stärkere Kompression ist daher nicht unbedingt immer besser, ich benutze für wichtige Dateien eher normales Zippen. Was auch noch extrem performant ist auf niedriger Kompressionsrate...

 

[Ohne Gehäuse]

Du denkst also ein Kompressionsverfahren zu entwicklen dass noch um Ecken besser ist als 7zip/WinRAR und co?

Ja.

Da sich die ganzen Top Programme gerade mal ein paar % Kompressionsunterschied geben bin ich doch sehr gespannt wie du das erreichen willst.

Indem mehr Computer power zum packen zur verfuegung steht.

Das verteilte Komprimieren/Dekomprimieren hört sich ja gut an, aber ist wohl erst bei großen Datenmengen sinnvoll wo ein einzelner PC ewig brauchen würde und da wird bei den meisten dann die Internetleitung wohl nicht mitspielen?!

Ab ca. 100-1000MB wird sich das System vermutlich lohnen.

Abgesehen davon in der Zeit der No-Limit Internetzugänge ist auch die Datenmenge nicht mehr relevant.
Vielleicht verstehe ich es falsch, aber selbst wenn du es schaffst einen 200MB Grafiktreiber auf 180MB zu verkleinern, muss dann für die Dekompression (welche aktuell innerhalb von 5 Sekunden fertig ist) wieder Daten hin und her geschickt werden und würde deiner Meinung nach wie lange dauern?

Falsch. Die Dekompression wuerde auf dem eigenen Rechner stattfinden. Auch lahme CPUs sollen eine Dekompressionsrate von ueber 100MB/s erreichen. Damit wuerde die dekompression deines Treibers nur noch ca. 2 bis 3 Sekunden daueren, bei einer hoffentlich kleineren Datei.

Abgesehen davon, beim Enduser anzufangen ist wohl der falsche Ansatz? Die komprimierten Dateien müssten wohl auf den Anbieter Servern liegen?

Nein, das System funktioniert so, ein User laedt eine Datei hoch auf einem Zentral Server, der Zentral Server leitet die Datei zum komprimieren auf das online Cluster weiter und kriegt sie dann spaeter wieder zurueck. Dann kann der User seine komprimierte Datei vom Zentral Server herunterladen. Zum dekomprimieren braucht der User nicht die Online Infrastruktur, das geht @Home mit seiner eigenen CPU.

Ich denke nicht dass viele User gewillt sind ihre neuen Grafiktreiber von www.bittegibmirviren.de runterzuladen?

Der Zentral Server wuerde von mir betrieben, und mir muesst ihr einfach vertrauen. Dritte Parteien (komprimier Clients) koennten die Datei allerdings nicht manipulieren da der Zentral Server ueberprueft ob sich die fertige komprimierte Datei auch zum exakten Original dekomprimieren laesst, wenn nicht dann wird halt das Stueck das fehlerhaft ist nochmal auf einem anderen Client komprimiert.

Ich verstehe das Prinzip noch nicht ganz.
Die Daten werden auf verschiedenen Rechnern übers Netz verteilt komprimiert/dekomprimiert. Das dadurch viel mehr Rechenpower vorhanden ist um die Dateien deutlich kleiner zu packen leuchtet mir noch ein.
Aber irgendwann muss dann doch die fertig entpackte Datei auf dem Rechner ankommen, der sie ursprünglich angefordert hat (z. B. einen PCGH Download). In dem Fall hilft es mir doch nicht, wenn die Datei superkleine .zip (so nenn ich sie der einfach mal) vom PCGH-Server "in die Cloud" geladen wird, dort entpackt wird um dann als riesige .exe auf meinem Rechner gespeichert zu werden. In diesem Fall muss ich ja doch den gesamten Download machen.

Wäre schön, wenn du darauf nochmal eingehen könntest. Danke!

Die Datei wird nicht in der Cloud entpackt, die kann mann selber mit hoher Speed entpacken.

Ich fasse das mal zusammen:
Erst muß ich Ewigkeiten warten, bis meine Dateien komprimiert sind, denn der begrenzende Faktor ist ja wohl die Bandbreite meines Internetanschlusses, und zwar der Upload.

Korrekt.

Dann muß ich den Strom für andere bezahlen, um Punkte zu sammeln, damit ich überhaut mal was komprimieren kann.
Derzeit ist noch keine Leistungssteigerung gegenüber den gängigen Packern zu erkennen.

Beides korrekt, allerdings zahlst du genauso viel Strom als wuerdest du die Datei Zuhause packen.

Also ich habe für sowas keinen Bedarf.
Außerdem dürfte es wohl auch nicht mehr lange dauern, bis GPGPU bei den Packprogrammen Einzug hält.

Viele Packungsalgorithmen koennen nicht einfach bzw. gar nicht mit Performance Vorteil auf GPUs portiert werden.

Ich hab das so verstanden, dass wenn ich jetzt einen DL von PCGH oder wo auch immer machen möchte, über eine Clientsoftware ala Downloadmanager die Datei jeweils stückchenweise von allen aktuell verfügbaren Clientrechnern geladen wird, dann jeweils komprimiert wird und an mich gesendet wird (alles andere macht in meinen Augen keinen, bzw. noch weniger Sinn).

Nein, PCGH haette vorher mit diesem System die Datei komprimiert. Als Downloader wuerdest du nur eine kleine Datei runterladen die du Zuhause schnell auf deinem eigenen Rechner entpacken kannst.

Das mit dem noch kleiner Komprimieren halte ich allerdings für nicht umsetzbar, 7zip, WinRAR und ZIP werden schon sehr nah am aktuell möglichen dran sein, und auch weiter forschen.

Siehe www.maximumcompression.com

Da findet mann eine Rangliste mit teils deutlich besseren Packungs Programmen als winrar, winZip etc. Allerdings ist die Performance meistens sehr schwach von diesen Programmen.

Das meiner Meinung nach beste ist die GPU zum komprimieren heranzuziehen. Das würde als einfaches Packprogramm sicherlich erfolgreich sein können.

Das Problem ist, bei den Algorithmen die ich nutze lohnt sich eine GPU erst bei sehr aggressiven Settings die sehr lange zum ausfuehren brauchen. Da ist dann der Vorteil das deine Datei innerhalb von Stunden auf der GPU gepackt wird, auf der CPU wuerde es vermutlich wochen dauern.

1. solange wie es noch keinen Allumfassenden 1 Gbit/s Anschluss Symetrisch gibt für Privatleute im Bezahlbaren Rahmen gibt, is deine Idee Müll.

Du findest also kleinere Downloads auf Downloads Seiten schlecht.....

Ausserdem muss jeder Komprimierungs Client nicht die ganze Datei herunterladen. Die Upload Rate zurueck zum Server duerfte durchschnittlich bei 4KB/s liegen.

2.

ähm nur so zur info ... auf meinen i7 - 2600 schaff ich das bereits ohne deine tolle Idee auf meiner SSD

Allerdings mit nicht sehr stark komprimierten Dateien....

3. Datensicherheit

Sachen wie Spiele Patches kann mann auch ohne Datensicherheits Vorkehrungen komprimieren. Empfindliche Daten sollten mit dem System natuerlich nicht komprimiert werden.

4.



ähm nein, da die idr schon gepackt sind, lassen die sich kaum noch mehr packen. Aufwand / Nutzen ungenügend

Die wuerden von der Download Seite dann ja im ungepackten Zustand auf dem Cluster gepackt und dann zum Download angeboten. Wenn ein PCGH User dann bei PCGH downloadet wuerde er wie gewohnt downloaden, nur das er eben eine kleinere Datei downloadet. PCGH muesste nur ein einziges Mal die Datei so aufwendig auf dem Cluster packen.

5.
LOL damit disqualifiziert das teil sich schon selber .... vorallem mit dem Letzten Satz. Und WinRAR benutzt nun schon nur die CPU

Lesen hilft, bisher wurde nur ein Kompressionsverfahren implementiert, dafuer sind die Resultate sogar erstaunlich gut. Die Theorie ist also, sobald mehrere Kompressionsverfahren implementiert sind duerfte die Kompression besser sein als von winrar, etc.

6.

Außerdem zu Punkt 2. Was Soll das für nen Sinn haben, wieder online zu dekomprimieren? Dann müssen die Daten ja 2 Geladen und einmal hochgeladen werden. Einmal komprimiert, dann hochladen zum dekomprimieren und einmal dekomprimiert untergeladen (und wieder schön groß)

Online-dekomprimierung wurde von mir niemals erwaehnt. Es wird nicht online dekomprimiert, das passiert zu Hause auf deinem eigenen Rechner.

Hättest du auch Interesse daran, aus dem Fenster zu springen, wenn ich dir verspreche, dass dir auf dem Weg nach unten Flügel wachsen?

Mitmachen kann ja nicht wirklich schaden und wenn ich den Source Code hier hochlade damit ihr selber kompilieren koennt sollte ausgeschlossen sein das schaedlicher Code auf dem Client ausgefuehrt wird.

Nehmen wir an du kriegst das hin - WER SOLL DIESE DATEN DENN DEKOMPRIMIEREN?! Nur Leute mit eigener ServerFarm???!?!?!??!



......totaler Bloedsinn

Ein kleiner ARM Prozessor sollte bereits halbwegs brauchbare Dekompressionsraten stemmen koennen (10MB/s).

Ähm... es ist ja nicht so, dass ich einige Sachen nicht verstehe sondern es ist so, dass ich das von vorne bis hinten nicht verstehe.

Erklär mir mal bitte eins:

Was ist so schwer daran, eine 100 MB Datei und 25MB zu bekommen ? Wenn du magst bau ich dir eine 1GB Text Datei und mach die kleiner als 25MB. Der Durchsatz wird dann auch weit über 100MB/s sein.

Wenn mann sagt das mann eine 1GB Datei auf 25MB komprimieren kann bedeutet das rein gar nichts. Wenn mann aber sagt das mann eine 100MB Datei auf 35MB komprimieren kann und winrar 28MB schafft dann hat das Bedeutung weil es ein Vergleich ist.

Online ist in Xfacher Hinsicht kompletter quatsch... Dazu muss eine Datei xmal hoch und runter oder zwischen Rechner hin und her verschickt werden. Das macht unterm Strich mehr Traffic als wenn ich die bereits gehostete Datei einfach runterlade und gut ist.

Wenn eine Webseite wie z.b. Computerbase einen Download anbietet der auf diese weise komprimiert wurde muessen die User nur diese kleine Datei herunterladen, wie schon mehrmals gesagt, es wird offline dekomprimiert.

Kann es sein, dass heute der 1. April ist und es keiner gemerkt hat ?

Das bashing liegt wohl eher daran das aus irgendeinem Grund alle meinen die Datei muesste auch online dekomprimiert werden, was natuerlich voellig sinnlos waere.

Das einzige was ich hier interessant finde ich CUDA (o.Ä.) mit ins Boot zu nehmen und wenn du das getan hättest, dann hättest du das patentieren sollen und Kohle scheffeln. Kannst du aber nicht mehr da du bereits davon erzählt hast. Schade mit den Gesetzen. Wenn du mich fragst hast du garnichts.

Habe nicht vor dieses System zu kommerzialisieren.

Weisste was ? Ich mach mit, einfach nur, weil ich das sehen will. Voraussetzungen dazu hat mein System ja. Ich steck auch gerne noch 3 Quadro Karten dazu, die ideln hier eh nur rum. Dann kannst du gleich noch Multi GPU implementieren.

Multi-GPU mit dynamischer Last Verteilung ist bereits implementiert.

@Hades85: Wer redet was schlecht? Wir wollen einfach den Sinn dahinter verstehen, wenn die Idee jemals was bringen soll muss es wohl auch nur im geringsten einen Sinn haben. Wenn der Traffic dadurch aber höher wird hat es 0 Sinn, wenn ich auf meine entpackten Dateien warten muss hat es 0 Sinn, wenn es von niemanden Unterstützt wird weil zu unsicher/kompliziert hat es 0 Sinn.

1. Traffic wird nicht hoeher da offline dekomprimiert wird und die Datei ja nur ein einziges mal komprimiert werden muss und dann zum Download angeboten werden kann.

2. Kompliziert wird es fuer den User nicht, zum hochladen der Datei wird es eine Webseite geben, wo mann auch sehen kann wie viele Punkte mann hat. Die Client Software wird lediglich eine .exe sein die mann ausfuehren muss, das wars. Unsicher wird es fuer sensible Daten sein, das stimmt, aber da laesst sich nichts machen. Fuer Spiele-Patches, Freeware Software etc. wird es aber geeignet sein.

Vielleicht verstehen wir ja auch alle sein Anliegen falsch, aber schlecht reden tut niemand wirklich was. Bis jetzt habe ich mehr oder minder sinnvolle Hinterfragung bzw. Kritik gelesen.

Ja, denn es wird offline dekomprimiert, nicht online. Und jede Datei muss ja nur einmal komprimiert werden, das heisst wenn die Dateien auf einer Download Seite als ein selbst entpackendes Archiv angeboten werden merkt der User nicht mal was, ausser natuerlich eine kleinere Datei und eine hoehere Dekompressionsrate.

Das Kommentar von Dr.Duschlampe war wohl eher auf die "ich bin bereit alles zu testen" Einstellung von dir gedacht - würdest du also auch ein Programm testen welches nur 2 GB deines RAM verbraucht aber nicht wirklich einen Sinn hat?
Bevor ich ein Programm teste muss ich wissen was es tut, ob es MIR was bringt und welche Risken ich dabei eingehen
Da ich nicht annehme dass man zum Programm auch den Source erhalten wird, bleibt es für mich ein Tabu, weil einen Keylogger einzubauen ist eine Kleinigkeit und ein Distributed Networking Programm wirst du in der Firewall eher nicht blocken

Der Source wird veroeffentlicht so dass jeder User genau ueberpruefen kann was die Software macht. Sich selbst die .exe erstellen kann der User dann auch.

Nicht falsch verstehen, ich würde ein Program auch testen wenn es mir nichts bringt, rein um zu helfen, aber einfach jedes Programm runterzuladen und zu testen ohne etwas zu hinterfragen wird nicht passieren.

Schau dir den Source an sobald er fertig ist und hier hochgeladen.

Vor nicht allzu langer Zeit (Feb 2013) gab es auf Tomshardware.de einen Test von 4 Packprogrammen. Die Ergebnisse der einzelnen Programme liegen weiter auseinander als ich das erwartet hätte. Es gibt also offensichtlich schon noch Optimierungsbedarf. Ich finde es auch sehr spannend, dass 7zip bei der .zip-Erstellung schneller und besser ist als winzip
Ich kann mir also schon vorstellen, dass es sinnvoll ist sich mit Komprimierung zu beschäftigen. Die Frage ist, ob der Cloud-Ansatz der praktikabelste ist?!

Der Cloud Ansatz ist praktikabler wenn es wochen dauert auf seinem eigenen Rechner die Datei zu komprimieren.

Von diesem speziellen Vorhaben halte ich nicht viel, weil erstens Komprimieren zeiteffizient lösbar ist mit ner stinknormalen CPU und zweitens wird das Verhältnis aus Dateigröße/Rechenzeit unendlich schlecht und die Dateigröße kaum noch kleiner bei höherer Kompression.

Das Verhaeltniss Dateigroesse/Rechenzeit ist schlecht, ja. Allerdings bei einer Download Seite wo ganz viele User downloaden kann jedes Byte eine differenz ausmachen.

Klarer Nachteil bei "besserer" Kompression sind z.B. auch die solid blocks. Das führt dazu, dass Deine gesamte Datei kaputt ist, sobald sie einen kleinen Fehler enthält. Stärkere Kompression ist daher nicht unbedingt immer besser, ich benutze für wichtige Dateien eher normales Zippen. Was auch noch extrem performant ist auf niedriger Kompressionsrate...

Stimmt, aber wie oft gibt es denn heutzutage noch uebertragungsfehler?

 

[Merlin-.-]

Die Frage ist doch, lohnt es sich, massig Strom zu verbrauchen (oben sprichst Du von "wochenlangem Packen" und ähnlichen Szenarien) beim Packen, um Volumen beim Download zu sparen.

Bevor Du da keine Kosten-/Nutzenrechnung vorlegst, ist das Projekt zwar nice-to-have, aber halt nur für Dich als Entwickler, der daran lernt und sich austobt...

Noch mal klar gesagt:
Meine Vermutung ist, dass Du den Stromverbrauch durch ein 10000 x langsameres Komprimieren, was dann nur 30% besser packt im allerbesten Fall (wenn Du Pech hast, 5%)., niemals wieder reinholst durch minimal kleinere Downloads.

Lass mich aber gern eines Besseren belehren, wenn Du was Überzeugendes vorbringen kannst.

PS:
Die Idee hat angesichts der Drosselkom-Affäre natürlich ihren Charme in Deutschland. Das nächste Problem ist dann, dass klassische Downloads wohl nicht das Gros des Traffics ausmachen. Da müsste jeder Videostream auch mit dieser Mörderkompression komprimiert werden... ^^

 

[SaarL]

Du müsstest erstmal Werte zeigen/belegen, was deine "Theorie" in der "Praxis" zu machen vermögt.
Sagen kann ich auch "ich will alle Dateien in 2s auf 4MB komprimieren", aber obs dann klappt

Pack ne(mehrere Typen, manche Dateien lassen sich ja besser packen als andere) Datei mit deinem "Programm" (welches ja noch nichtmal existiert?!) und einmal mit den üblichen Verdächtigen und poste hier das Ergebnis.
Alles davor ist nutzlos zu diskutieren imo.

 

[Console Cowboy]

Ist doch 'ne feine Idee,

leider scheint bei einigen Kommentatoren ein Missverständniss vorzuliegen:
Wer jetzt mitmacht hat KEINE Vorteile, sondern unterstützt die Entwicklung
eines Packers, der hoffentlich in Zukunft grösseren Downloadanbietern
ermöglichen soll, zum Wohle aller Nutzer verkleinerte Datenpakete anzubieten.

@ohne gehäuse - korrigier mich bitte, wenn ich falsch liege.

Gruß
CC

 

[Sebbi]

so, ich habs mal bissl durchdacht und gemerkt, das es einfach ineffizent aufgrund der benötigen Anzahl der Rechner, um das effektiv vorteilhafter zu gestalten. Der Stromverbrauch der gesammten "Arbeiter" ist einfach viel höher, als wie wenn das per Standardzip gepackt wird, und halt der Downloader 25% Länger dran läd.

ein kleiner vergleich .... 11 MB Logdatein der Windows Ereigniss Anzeige

7zip 415 KB -> 4 Sekunden Komprimierzeit
WinRAR 445 KB -> 2 Sekunden
WinRK 188 KB -> 5 Minuten

wenn man bedenkt, das die GPU ein Vielfaches von den Stromverbrauch einer CPU hat .... naja und selbst wenn du nur ein kleines Stück berechnest auf jeder GPU

Übrigens musst du jedes Packet mindestens 2 mal von verschiedenen Rechnern komprimieren lassen, um zu sehen, ob sich nicht jemand verrechnet hat. DH das halbiert nochmal die Effizenz.

also du kannst gerne einen GPU Packer entwickeln .... aber das dann als verteiltes Rechnen .... vergiss es. Sowas ist für komplizierte und langwirige Berechnungen von etwas, mit dem du selber arbeiten musst, aber nichts für Kompressionen von Daten.

 

[Visceroid]

Danke für die Aufklärungen, es lagen ja offensichtlich einige Missverständnisse vor die jetzt größtenteils aufgeklärt sind.

Zum System allgemein noch: wenn, wie du schreibst, der User durch komprimieren Punkte sammeln muss um selbst was komprimieren zu können - denkst du nicht auch dass viele User nur das dekomprimieren am lokalen Rechner nutzen werden? Sollte es im Client keine Option geben das komprimieren und den damit verbundenen Up/Download abzuschalten (Metered Connections wo es MB/GB Limits gibt z.B.) werden wohl viele User wieder davor zurückschrecken?

Ich meine, kleinere Downloads hören sich verlockend an aber, wie viele User schreiben, machen Downloads nur einen kleinen Teil des Gesamtvolumens aus. Auch wenn im Schnitt jetzt nur 4kb/s verwendet werden für den Client summiert sich dass doch und wird bei 24/7 Betrieb auf ~345MB/Tag kommen. Wenn du es schaffst dass Downloads im Schnitt 10% kleiner werden (das ist laut maximumcompression.com vielleicht noch drinnen gegenüber winrar/7zip) müsstest du ca. 3.5GB/Tag verkleinerbare Dateien runterladen damit man einen Vorteil hat.
Vom Stromverbrauch rede ich hier nicht, da es jedem User überlassen bleibt ob er sein System 24/7 laufen hat und auslasten lässt oder nicht, da braucht sich keiner Aufregen - gezwungen wird keiner zu etwas.

Der Zentral Server wuerde von mir betrieben, und mir muesst ihr einfach vertrauen. Dritte Parteien (komprimier Clients) koennten die Datei allerdings nicht manipulieren da der Zentral Server ueberprueft ob sich die fertige komprimierte Datei auch zum exakten Original dekomprimieren laesst, wenn nicht dann wird halt das Stueck das fehlerhaft ist nochmal auf einem anderen Client komprimiert.

Abgesehen von allen anderen Vor/Nachteilen sehe ich das wahrscheinlich als Knackpunkt an. Was motiviert Betreiber wie PCG/CB/heise und wie sie alle heißen, Dateien bei dir hoch zu laden und irgendwann wieder runter zu laden um auf Ihren Servern anbieten zu können?
Jede Seite die das System nutzt könnte die kleinen Downloads also erst etwas/viel (je nach Anzahl der User und Auslastung des Distributed-Netzwerkes) später anbieten.
Das kleinere Datenvolumen wird sich zwar über Dauer rechnen aber der Unsicherheitsfaktor bleibt. Boykottiert dich nur eine große Downloadseite, wird das System wohl kollabieren da sich der Enduser fragen wird ob es was bringt den Client zu installieren wenn eh nicht alle Seiten wo er runter lädt unterstützt werden?

Kollabiert das System nicht, stellt sich mir die Frage ob ein einzelner User, der nicht mal Geld damit machen will, ausreichend Infrastruktur zur Verfügung stellen kann um ein derartiges Volumen zu handlen? Nur die gestrigen Computerbase Downloads, gezählt nur wo eine Größe angezeigt wurde, haben zusammen 793MB. Siehst du dir andere Tage an, wirst du sehen dass es teilweise noch wesentlich mehr ist.
Egal ob es nun der Upload/Speicherplatz/Download wird - das Volumen wird bei einem Erfolg des Systems gewaltig werden.
Wenn du nur 1000 Client User hast, sind das ~4MB/sek! Gerechnet noch ohne die Down/Uploads der Anbieter!

 

[Ohne Gehäuse]

Die Frage ist doch, lohnt es sich, massig Strom zu verbrauchen (oben sprichst Du von "wochenlangem Packen" und ähnlichen Szenarien) beim Packen, um Volumen beim Download zu sparen.

Wenn nur eine Person von der Download Seite die Datei runterlaedt wird es sich wohl nicht lohnen, wenn aber tausende die Datei herunterladen spart die Downloadseite etwas Traffic und die User muessen nicht so lange beim runterladen und entpacken warten.

Bevor Du da keine Kosten-/Nutzenrechnung vorlegst, ist das Projekt zwar nice-to-have, aber halt nur für Dich als Entwickler, der daran lernt und sich austobt...

Da hast du vermutlich recht, ich denke ich werde noch ein paar Tests durchfuehren sobald ein neues Kompressionsverfahren implementiert ist und sobald einige gravierende Bugs behoben sind.

Noch mal klar gesagt:
Meine Vermutung ist, dass Du den Stromverbrauch durch ein 10000 x langsameres Komprimieren, was dann nur 30% besser packt im allerbesten Fall (wenn Du Pech hast, 5%)., niemals wieder reinholst durch minimal kleinere Downloads.

Da koenntest du recht haben, das muss mann herausfinden.

Lass mich aber gern eines Besseren belehren, wenn Du was Überzeugendes vorbringen kannst.

PS:
Die Idee hat angesichts der Drosselkom-Affäre natürlich ihren Charme in Deutschland. Das nächste Problem ist dann, dass klassische Downloads wohl nicht das Gros des Traffics ausmachen. Da müsste jeder Videostream auch mit dieser Mörderkompression komprimiert werden... ^^

Fuer Videostreams sind andere Kompressionsmethoden besser geeignet, winrar, 7z und winZip sind auch nicht optimal fuer Videokompression. Was mann versuchen koennte ist den bereits komprimierten Videostream nochmals mit dieser Methode zu komprimieren, es ist aber eher unwahrscheinlich das das irgendwas bringt da es meist aussichtslos ist bereits komprimierte Daten zu komprimieren.

Du müsstest erstmal Werte zeigen/belegen, was deine "Theorie" in der "Praxis" zu machen vermögt.
Sagen kann ich auch "ich will alle Dateien in 2s auf 4MB komprimieren", aber obs dann klappt

Die Software ist ja noch in der Entwicklung, da muss mann erst warten bis die Software halbwegs lauffaehig ist.

Pack ne(mehrere Typen, manche Dateien lassen sich ja besser packen als andere) Datei mit deinem "Programm" (welches ja noch nichtmal existiert?!) und einmal mit den üblichen Verdächtigen und poste hier das Ergebnis.
Alles davor ist nutzlos zu diskutieren imo.

Das Programm ist seit ca. 2 Wochen in Entwicklung. Was bisher "halbwegs" funktioniert:

- Erstes Kompressionsverfahren
- Mutli-GPU
- Dynamische Lastverteilung

Deinen Vorschlag werde ich ausfuehren sobald die Software in einem spaeteren Entwicklungsstadium ist.

Ist doch 'ne feine Idee,

leider scheint bei einigen Kommentatoren ein Missverständniss vorzuliegen:
Wer jetzt mitmacht hat KEINE Vorteile, sondern unterstützt die Entwicklung
eines Packers, der hoffentlich in Zukunft grösseren Downloadanbietern
ermöglichen soll, zum Wohle aller Nutzer verkleinerte Datenpakete anzubieten.

@ohne gehäuse - korrigier mich bitte, wenn ich falsch liege.

Gruß
CC

Das trifft den Nagel auf den Kopf.

so, ich habs mal bissl durchdacht und gemerkt, das es einfach ineffizent aufgrund der benötigen Anzahl der Rechner, um das effektiv vorteilhafter zu gestalten. Der Stromverbrauch der gesammten "Arbeiter" ist einfach viel höher, als wie wenn das per Standardzip gepackt wird, und halt der Downloader 25% Länger dran läd.

Da hast du Recht, fuer einzelne Dateien fuer individuelle User ist das System viel zu aufwaendig und ineffizient. Fuer Downloadseiten koennte sich der Aufwand allerdings lohnen.

ein kleiner vergleich .... 11 MB Logdatein der Windows Ereigniss Anzeige

7zip 415 KB -> 4 Sekunden Komprimierzeit
WinRAR 445 KB -> 2 Sekunden
WinRK 188 KB -> 5 Minuten

wenn man bedenkt, das die GPU ein Vielfaches von den Stromverbrauch einer CPU hat .... naja und selbst wenn du nur ein kleines Stück berechnest auf jeder GPU

Da sieht mann auch schoen das es durchaus moeglich ist 7zip, Winrar etc. deutlich zu schlagen.

Übrigens musst du jedes Packet mindestens 2 mal von verschiedenen Rechnern komprimieren lassen, um zu sehen, ob sich nicht jemand verrechnet hat. DH das halbiert nochmal die Effizenz.

Nein, der Zentralserver wuerde erst ueberpruefen ob sich jedes Packet entpacken laesst, wenn nicht dann muss ein anderer Client es ein zweites mal entpacken, das dies passiert sollte aber nicht zur Regel gehoeren, also in 999/1000 Faellen duerfte es nicht noetig sein ein Packet mehr als einmal zu packen.

also du kannst gerne einen GPU Packer entwickeln .... aber das dann als verteiltes Rechnen .... vergiss es. Sowas ist für komplizierte und langwirige Berechnungen von etwas, mit dem du selber arbeiten musst, aber nichts für Kompressionen von Daten.

Problem ist, GPU Packer die einen wirklich grossen Leistungsunterschied zur CPU aufweisen brauchen meines Wissens nach sehr agressive Komprimiersettings um deutlich schneller als die CPU zu sein. In den ersten Tests wird das auch mehr als deutlich.

Danke für die Aufklärungen, es lagen ja offensichtlich einige Missverständnisse vor die jetzt größtenteils aufgeklärt sind.

Zum System allgemein noch: wenn, wie du schreibst, der User durch komprimieren Punkte sammeln muss um selbst was komprimieren zu können - denkst du nicht auch dass viele User nur das dekomprimieren am lokalen Rechner nutzen werden?

Sicherlich wuerde der Grossteil der User nur den dekomprimierer nutzen. Allerdings kann mann hoffen das einige User beim komprimieren mitmachen wuerden zum Wohle aller um kleinere Downloads auf diesen Seiten zu bekommen. Bei Folding@Home machen ja auch viele mit ohne direkten Vorteil fuer sich selbst. Was auch noch eine Moeglichkeit ist, mann bietet den Downloadseiten an die Downloads auf einem dedizierten Cluster zu komprimieren, das wuerde dann allerdings Geld kosten, zumindest waere das eine Option wenn wenig User online sind zum komprimieren. Das System sollte dann aber dynamisch sein so dass der dedizierte Cluster und die User zusammen arbeiten koennten.

Sollte es im Client keine Option geben das komprimieren und den damit verbundenen Up/Download abzuschalten (Metered Connections wo es MB/GB Limits gibt z.B.) werden wohl viele User wieder davor zurückschrecken?

Gute Idee, das wird dann implementiert.

Ich meine, kleinere Downloads hören sich verlockend an aber, wie viele User schreiben, machen Downloads nur einen kleinen Teil des Gesamtvolumens aus. Auch wenn im Schnitt jetzt nur 4kb/s verwendet werden für den Client summiert sich dass doch und wird bei 24/7 Betrieb auf ~345MB/Tag kommen. Wenn du es schaffst dass Downloads im Schnitt 10% kleiner werden (das ist laut maximumcompression.com vielleicht noch drinnen gegenüber winrar/7zip) müsstest du ca. 3.5GB/Tag verkleinerbare Dateien runterladen damit man einen Vorteil hat.

3.5GB Download pro Tag verteilt auf mehrere Clients sollten doch kein Problem sein. Der Zentral Rechner wird vermutlich ein VPS mit 1Gbit/s connection.

Abgesehen von allen anderen Vor/Nachteilen sehe ich das wahrscheinlich als Knackpunkt an. Was motiviert Betreiber wie PCG/CB/heise und wie sie alle heißen, Dateien bei dir hoch zu laden und irgendwann wieder runter zu laden um auf Ihren Servern anbieten zu können?
Jede Seite die das System nutzt könnte die kleinen Downloads also erst etwas/viel (je nach Anzahl der User und Auslastung des Distributed-Netzwerkes) später anbieten.

Die Download Seite koennte die Downloads direkt nach Release noch als .rar, .7z oder .zip Dateien anbieten waehrend gleichzeitig auf dem Cluster die Dateien im andern Format komprimiert werden, sobald das fertig ist, werden die Downloads halt im neuen Format angeboten.

Das kleinere Datenvolumen wird sich zwar über Dauer rechnen aber der Unsicherheitsfaktor bleibt. Boykottiert dich nur eine große Downloadseite, wird das System wohl kollabieren da sich der Enduser fragen wird ob es was bringt den Client zu installieren wenn eh nicht alle Seiten wo er runter lädt unterstützt werden?

Mann koennte die Downloads als selbst-entpackendes Archiv anbieten. Der Download duerfte dadurch nur 27KB groesser werden.

Kollabiert das System nicht, stellt sich mir die Frage ob ein einzelner User, der nicht mal Geld damit machen will, ausreichend Infrastruktur zur Verfügung stellen kann um ein derartiges Volumen zu handlen? Nur die gestrigen Computerbase Downloads, gezählt nur wo eine Größe angezeigt wurde, haben zusammen 793MB. Siehst du dir andere Tage an, wirst du sehen dass es teilweise noch wesentlich mehr ist.
Egal ob es nun der Upload/Speicherplatz/Download wird - das Volumen wird bei einem Erfolg des Systems gewaltig werden.
Wenn du nur 1000 Client User hast, sind das ~4MB/sek! Gerechnet noch ohne die Down/Uploads der Anbieter!

Mann koennte ja erstmal nur die populaersten Downloads mit dem Verfahren komprimieren. Den Clients koennte zur Hilfe ein dedizierter Cluster zur Seite stehen, hier ist die Finanzierung allerdings das Problem da vermutlich viele Download Seiten nicht bereit waeren fuer kleinere Downloads zu zahlen.