pgrusts Gravity-Engine schlägt ClickHouse im eigenen Benchmark um das Dreifache

> Normalerweise arbeiten Ingenieure, wenn sie Software schneller machen wollen, von unten nach oben. Sie führen einen Benchmark aus, schauen sich ein Flamegraph an, finden einen Hotspot und überlegen, wie sie ihren Code um 15 % oder 20 % beschleunigen können. Das Problem bei der Arbeit von unten nach oben ist, dass man nicht weiß, wo die Obergrenze liegt. Man ist vielleicht 20 % von dem schnellstmöglichen Code entfernt, den die Hardware ausführen kann, oder vielleicht 100x davon.

> Als wir anfingen, Gravity zu bauen, haben wir diese Frage umgedreht. Wir haben uns gefragt: Wie schnell kann eine Datenbank tatsächlich sein? Anstatt unsere bestehende Query-Engine schrittweise zu beschleunigen, wollten wir von der physischen Geschwindigkeitsgrenze unserer Hardware und unseres Dateiformats ausgehen und uns rückwärts vorarbeiten. Ich nenne das gerne „Programmieren mit Lichtgeschwindigkeit“.

Was als der „normale“ Ansatz zur Code-Optimierung beschrieben wird, ist eigentlich eher der „naive“ Ansatz. Jede ernsthafte Performance-Optimierungsarbeit würde dem Ansatz folgen, zuerst zu definieren, was die Obergrenze ist, die die Hardware zulässt, und dagegen zu benchmarken. Und das war schon vor LLMs so.

Siehe zum Beispiel: https://www.marginalia.nu/log/a_106_native_calls/

Entschuldigung für die Haarspalterei, aber ich dachte, es könnte für andere Leser nützlich sein, einzuordnen, dass dieser Teil des Ansatzes nicht neu ist. Ihre Verwendung von Claude, um diese optimierten Benchmarks zu generieren, ist schon interessant genug, daher halte ich es nicht für nötig, diesem Teil in ihrem Artikel zusätzliche Aufmerksamkeit zu schenken.