Neuer Rekord bei Datenkompression: US-Entwickler gewinnt Preis

[HWL News Bot]

Ein US-Softwareentwickler aus New York hat kürzlich einen neuen Rekord in Sachen Datenkompression aufgestellt. Saurabh Kumar schaffte es einen Datensatz aus der Online-Enzyklopädie Wikipedia, in der Größe von einem Gigabyte, auf nur noch 11,41 % seiner ursprünglichen Größe zu komprimieren, im Ergebnis auf 114.156.155 Byte. Damit gelang es Kumar dem von deutschen Informatiker und Professor Marcus Hutter initiierten Hutter-Preises zu gewinnen und gleichsam einen neuen Rekord aufzustellen. Ziel des Wettbewerbs ist es, eine maximale Komprimierung bei vollständiger und verlustfreier Wiederherstellung der ursprünglichen Daten zu erreichen.
... weiterlesen

 

[_Chris]

Interessant: Golem verweist beim Testsystem auf ein Dell Latitude E6510, welches der Dell-Spec nach (https://i.dell.com/sites/csdocument...cuments/en/latitude-e6410-e6510-specsheet.pdf) nur 2 RAM-Slots mit max. 4GB RAM erlaubt, also 8GB total. Weiterhin definiert der Hutter-Test laut Golem-Beschreibung jedoch ein RAM-Limit von max. 10GB, die in dem Testsystem eigentlich nicht erreicht werden können.

 

[Infi88]

Was sollte daran interessant sein, das er ein für den Wettbewerb entsprendende Konfiguration mit maximal 8GB(8192 MB) verwendet hat damit er die 10GB Arbeitsspeicher nicht überschreitet ? Wäre er damit intellektuell überfordert gewesen wie der durchschnittliche Golem Leser, hätte er den Preis wohl nicht eingesackt.

 

[_Chris]

Ist anders herum gemeint: Golem zufolge gibt der Hutter-Test das Latitude vor. Gleichzeitig definiert der Hutter-Test, dass maximal 10G RAM verwendet werden dürfen.

 

[n3cron]

Kein Wunder das wir noch im Zeitalter des Singlecores sind, wenn die Preise noch vorgaben machen nicht mehr als einen Singlecore zu verwenden.

Ich dachte hier soll dabei wirklich ein neuartiger moderner Algorithmus dabei herauskommen der eben im Alltag nutzbar ist und nicht fiktiv wissenschaftlich für einen Wettbewerb.

Totaly useless.

 

[YCbCr]

Interessant: Golem verweist beim Testsystem auf ein Dell Latitude E6510, welches der Dell-Spec nach (https://i.dell.com/sites/csdocument...cuments/en/latitude-e6410-e6510-specsheet.pdf) nur 2 RAM-Slots mit max. 4GB RAM erlaubt, also 8GB total. Weiterhin definiert der Hutter-Test laut Golem-Beschreibung jedoch ein RAM-Limit von max. 10GB, die in dem Testsystem eigentlich nicht erreicht werden können.

Die Angaben sind auch einfach (sowohl hier, als auch bei Golem) falsch.

Die aktuellen Regeln diesbezüglich lauten:

Each program must run in less than 70'000/T hours on a machine using at most 10GB RAM and 100GB HDD for temporary files, where T is the machine's Geekbench5 score. No GPU usage.
In particular they must run on our current test machines, which are as of 2021 (but may change without notice) a Lenovo 82HT Intel Core i7-1165G7 2.79GHz (Windows) with T≈1427 (1 core) and T≈4667 (4 cores) and an AMD Ryzen 7 3.6GHz (Linux) with T=1310 (1 core) and T=8228 (8 cores)

Das mit dem E6510 stammt noch aus Zeiten (2017-2021) als es 20000 / Geekbench4 Score Stunden, 1 GB RAM und 10 GB HDD waren.
Davor waren es "10 hours on a 2GHz Pentium 4 with 1GB RAM and 10GB free HD".

Die Aufgabenbeschreibung verlinkt allerdings noch auf das alte Testsystem (in dem im übrigen nur 4 GB verbaut waren). Wie man auf die 50h kommt ist mir allerdings auch ein Rätsel, da der verlinkte GB Score nach beiden Regelwerken zu weniger Zeit führt.

Kein Wunder das wir noch im Zeitalter des Singlecores sind, wenn die Preise noch vorgaben machen nicht mehr als einen Singlecore zu verwenden.

Ich dachte hier soll dabei wirklich ein neuartiger moderner Algorithmus dabei herauskommen der eben im Alltag nutzbar ist und nicht fiktiv wissenschaftlich für einen Wettbewerb.

Totaly useless.

Die Gründe für diese Vorgabe sind recht ausführlich erörtert und imo gut begründet.

Was Alltagstauglichkeit angeht würde ich sagen, dass das Gegenteil der Fall ist. Man muss bedenken, dass parallelisieren der Aufgabe nicht durch parallelisieren des Algorithmus an sich erreicht werden muss.
Für den Wettbewerb soll ein 1GB auszug aus Wikipedia komprimiert werden; ein kompletter XML Dump der englischen Wikipedia (inklusive Verlauf, Diskussionen, etc.) hatte schon 2015 10 TB. Das sind eine Menge 1GB "Blöcke" die man parallel komprimieren könnte.
Ein anderes Beispiel wäre ein Hauptanwendungsgebiet für Textkompression heutzutage: Das www. Ein einigermaßen ausgelasteter Webserver verarbeitet zu jeder Zeit mehr Anfragen (deren Antwort er unabhängig voneinander komprimiren kann) als Kerne vorhanden sind.

 

[n3cron]

Die Gründe für diese Vorgabe sind recht ausführlich erörtert und imo gut begründet.

The primary intention is to limit compute and memory to some generally available amount in a transparent, easy, fair, and measurable way.

Ja hab ich ja gesagt, wissenschaftlich. Dabei geht es nicht um alltags Tauglichkeit sondern nur Vergleichbarkeit. Dachte ich mir schon.