2026-01-06
DuckDB auf LoongArch
Hannes Mühleisen
Nicht jeden Tag landet eine neue CPU-Architektur auf dem Schreibtisch. Ich bin Anfang der 90er mit dem Intel 486 aufgewachsen. Ich erinnere mich auch noch, wie AMD 2000 seine 64-Bit-x86-Erweiterung veröffentlicht hat. Danach passierte lange nichts, bis Apple 2020 die ARM-basierte M1-Architektur vorgestellt hat. Aber heute ist wieder so ein Tag (für mich), mit der lang erwarteten Ankunft des „MOREFINE M700S“ in unserem Büro.
Der M700S enthält eine Loongson-CPU. Auch „LoongArch“ oder „Godson“ genannt, wurde diese CPU in China auf Basis der (etwas esoterischen) MIPS-Architektur entwickelt. Das gehört zu einem Plan zur technologischen Selbstversorgung im Rahmen des staatlich geförderten Made in China 2025-Plans.
Es ist wohl sicher anzunehmen, dass der Loongson – angesichts der laufenden Handelswirren – in China mit der Zeit deutlich populärer wird. DuckDB sieht bereits ziemlich viel Nutzung aus China, also wollen wir natürlich sicherstellen, dass DuckDB auf dem Loongson gut läuft. Glücklicherweise hat ein Community-Mitglied bereits einen Pull Request mit zwei minimalen Änderungen geöffnet, damit DuckDB kompiliert. Wir wurden neugierig.
Wir haben den M700S (wo sonst?) auf AliExpress für etwa 500 EUR gekauft. Neben der Loongson-8-Kern-3A6000-CPU enthält er 16 GB Hauptspeicher und eine 256-GB-SSD.
Einmal eingesteckt und gebootet fühlt sich alles ziemlich normal an, abgesehen vom lauten Lüfter, der immer zu laufen scheint. Auf dem Bildschirm startet eine Debian-Variante namens Loongnix. Die GUI wirkt KDE-basiert und kommt mit einem eigenen Browser „LBrowser“, einem Chromium-Fork. Nur weil es nicht offensichtlich war, dokumentieren wir es hier: Das Standard-root-Passwort ist M700S. Es gibt auch einen Benutzeraccount m700s mit demselben Passwort.
Insgesamt wirkt die Software etwas betagt, selbst nach apt upgrade: Der Linux-Kernel scheint Version 4.19 zu sein, 2018 erschienen und seit einem Jahr EOL. Die GCC-Version ist 8.3, ebenfalls 2019 herausgekommen.
Mit dem erwähnten Patch konnten wir DuckDB 1.4.3 auf Loongnix kompilieren. Es gab ein kleines Problem, bei dem die CMake-Datei append_metadata.cmake nicht mit der älteren CMake-Version (3.13.4) auf Loongnix kompatibel war. Einfach diese Datei durch eine leere zu ersetzen hat den Build aber durchgelassen. Natürlich hätten wir CMake auch aktualisieren können, aber das Leben ist kurz. Danach haben wir DuckDBs umfangreiche Unit-Testsuite (make allunit) ausgeführt, um zu bestätigen, dass unser Build auf der Loongson-CPU korrekt läuft. Die Ergebnisse sahen gut aus.
Für den Performance-Vergleich haben wir die Methodik aus unserem vorherigen Blogbeitrag wiederverwendet, in dem DuckDB auf einem Raspberry Pi gelaufen ist. Kurz: Wir führen die 22 TPC-H-Benchmark-Abfragen auf „Scale Factor“ 100 und 300 aus, das sind im DuckDB-Format eine 25-GB- bzw. 78-GB-Datenbankdatei. Wir vergleichen diese Zahlen mit dem nächstliegenden Computer, meinem Alltag-MacBook Pro mit M3-Max-CPU. Der Fairness halber begrenzen wir DuckDB auf beiden Plattformen auf 14 GB RAM. Die angegebenen Zeiten sind „Hot Runs“, das heißt wir haben den Query-Satz erneut ausgeführt und die Zeiten vom zweiten Lauf genommen.
Hier die Ergebnisse, und sie sind nicht großartig. Wir beginnen mit aggregierten Zeiten:
| SF | System | Geometric mean | Sum |
|---|---|---|---|
| SF100 | MacBook | 0.6 | 16.9 |
| SF100 | MOREFINE | 6.1 | 192.8 |
| SF300 | MacBook | 2.8 | 78.8 |
| SF300 | MOREFINE | 27.3 | 791.6 |
Wir sehen, dass das MacBook auf diesem Benchmark rund zehnmal schneller ist als der MOREFINE, sowohl im geometrischen Mittel der Laufzeiten als auch in der Summe. Wenn Sie die einzelnen Query-Laufzeiten interessieren, finden Sie sie unten.
Klicken Sie hier, um die einzelnen Query-Laufzeiten zu sehen.
| Q | SF100/MacBook | SF100/MOREFINE | SF300/MacBook | SF300/MOREFINE |
|---|---|---|---|---|
| 1 | 1.247 | 7.363 | 4.528 | 26.475 |
| 2 | 0.117 | 1.058 | 0.474 | 4.101 |
| 3 | 0.697 | 8.563 | 2.759 | 32.432 |
| 4 | 0.570 | 7.348 | 2.331 | 27.185 |
| 5 | 0.631 | 8.498 | 3.217 | 34.462 |
| 6 | 0.180 | 1.236 | 1.395 | 13.225 |
| 7 | 0.620 | 7.702 | 3.119 | 37.411 |
| 8 | 0.640 | 5.593 | 3.611 | 29.914 |
| 9 | 1.906 | 30.560 | 6.670 | 99.884 |
| 10 | 0.923 | 11.755 | 4.036 | 40.412 |
| 11 | 0.102 | 1.037 | 0.709 | 4.444 |
| 12 | 0.535 | 6.422 | 2.918 | 31.501 |
| 13 | 1.847 | 21.185 | 6.394 | 74.081 |
| 14 | 0.408 | 5.616 | 3.240 | 26.613 |
| 15 | 0.252 | 2.652 | 1.906 | 17.454 |
| 16 | 0.273 | 3.108 | 0.879 | 11.480 |
| 17 | 0.805 | 5.184 | 4.655 | 28.469 |
| 18 | 1.538 | 15.492 | 7.619 | 71.845 |
| 19 | 0.779 | 9.143 | 4.379 | 39.111 |
| 20 | 0.441 | 4.993 | 3.234 | 25.967 |
| 21 | 1.996 | 23.231 | 9.503 | 96.452 |
| 22 | 0.441 | 5.036 | 1.237 | 18.709 |
Es ist immer aufregend, DuckDB auf einer neuen Plattform zum Laufen zu bringen. Natürlich haben wir DuckDB so gebaut, dass es ultra-portabel und agnostisch gegenüber Hardware-Umgebungen ist und trotzdem exzellente Performance liefert. Es war also nicht so überraschend, dass DuckDB auf dem MOREFINE mit seiner eher neuen CPU nicht so schwer zum Laufen zu bringen war. Die Performance auf dem Standard-TPC-H-Benchmark war allerdings nicht so beeindruckend: Das MacBook ist rund zehnmal schneller als der MOREFINE.
Natürlich gibt es viele Verbesserungsmöglichkeiten. Zum einen ist die gcc-Toolchain auf LoongArch bei weitem nicht so weit wie ihr x86/ARM-Gegenstück, Fortschritte dort könnten einen großen Unterschied machen. Dasselbe gilt natürlich für die I/O-Performance, die wir nicht separat gemessen haben. Aber hey, die „Glas halb voll“-Abteilung könnte auch zu Recht behaupten, dass die Loongson-CPU TPC-H SF300 abschließen kann!
Man könnte auch argumentieren, dass ein MacBook Pro deutlich teurer ist als der 500-EUR-MOREFINE. Ein aktueller M4 Mac Mini mit denselben Speicher- und Storage-Specs kostet aber rund 700 EUR, alles in allem nicht so viel mehr. Er wird Kreise um den MOREFINE ziehen. Und er wird Sie nicht ständig mit seinem Lüfter nerven.