An Empirical Comparison of General Context-Free Parsers
Dieses Paper präsentiert den ersten vereinheitlichten Benchmark von sechs allgemeinen kontextfreien Parsing-Algorithmen, die in Rust implementiert wurden, und zeigt auf, dass die GLR-Familie eine praktische Standardwahl für Software-Engineering-Werkzeuge darstellt, indem sie im Vergleich zu deterministischen LR(1)-Parsern nur einen moderaten medianen Leistungsoverhead von etwa dem 3-fachen verursacht, während sie gleichzeitig die volle Ausdrucksstärke der Sprache unterstützt.
Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen
Stellen Sie sich vor, Sie sind ein Übersetzer, der versucht, eine Fremdsprache (Quellcode) in etwas umzuwandeln, das ein Computer verstehen kann. Dieser Prozess wird als Parsing bezeichnet.
Über Jahrzehnte hinweg waren die Übersetzer, die Softwareentwickler verwendeten, wie strenge, regelgebundene Roboter. Sie waren unglaublich schnell, aber auch sehr wählerisch. Wenn die Sprache, die Sie ihnen gaben, auch nur ein klein wenig mehrdeutig war oder eine komplexe Satzstruktur aufwies, weigerte sich der Roboter zu arbeiten. Um den Roboter glücklich zu machen, mussten Ingenieure Stunden damit verbringen, die Sprache zu „hacken“ – Sätze umzuschreiben, natürliche Strukturen zu entfernen und die Grammatik so zu verbiegen, dass sie gerade noch in die engen Regeln des Roboters passte. Es war, als würde man versuchen, einen runden Klotz in ein quadratisches Loch zu pressen, nur weil man eben nur quadratische Klötze besaß.
Aus diesem Grund gaben viele Ingenieure auf, diese formalen Roboter überhaupt zu verwenden, und begannen stattdessen, ihre eigenen Übersetzer von Hand zu bauen. Diese handgebauten Übersetzer sind oft fehlerhaft, schwer zu warten und unsicher.
Die große Frage
Jahrelang herrschte der Glaube vor, dass „allgemeine“ Parser – Übersetzer, die jede Sprachstruktur verarbeiten können, ohne dass man sie hacken muss – zu langsam wären, um nützlich zu sein. Man dachte, sie seien wie ein langsamer, tollpatschiger Riese im Vergleich zum schnellen, strengen Roboter.
Die Autoren dieser Arbeit beschlossen, die Debatte zu klären. Sie bauten eine „Rennstrecke“, um sechs verschiedene Arten dieser „allgemeinen“ Parser gegen die alten „strengen“ Roboter zu testen. Sie stellten sicher, dass jeder Rennfahrer die gleichen Schuhe, die gleiche Strecke und die gleiche Stoppuhr verwendete (sie schrieben den gesamten Code in derselben Sprache, Rust, unter Verwendung derselben Werkzeuge).
Die Rennfahrer
Sie testeten sechs verschiedene Strategien:
- Die Matrix-Beweger (CYK & Valiant): Diese versuchen, das Rätsel zu lösen, indem sie ein riesiges Gitter ausfüllen.
- Die Top-Down-Entdecker (Earley & GLL): Diese versuchen, die Struktur von oben nach unten zu erraten, indem sie viele Pfade gleichzeitig erkunden.
- Die Bottom-Up-Konstrukteure (RNGLR & BRNGLR): Diese bauen die Struktur von unten nach oben auf und bewältigen Konflikte, indem sie ihre Aufmerksamkeit gleichzeitig auf mehrere Pfade aufteilen.
- Die strengen Roboter (LL(1) & LR(1)): Die altmodischen, schnellen, aber wählerischen Parser.
Die Ergebnisse: Der überraschende Gewinner
- Die „tollpatschigen Riesen“ (CYK & Valiant): Diese waren schrecklich. Sie waren so langsam, dass sie für reale Aufgaben praktisch unbrauchbar waren. Es ist, als würde man versuchen, mit einem Panzer durch eine Stadt zu fahren; das funktioniert einfach nicht gut.
- Die „Top-Down-Entdecker“ (Earley & GLL):
- Earley war der langsamste der Gruppe.
- GLL war schnell bei einigen Sprachen, wurde aber bei anderen sehr langsam und speicherhungrig. Es war wie ein Läufer, der auf einer geraden Bahn großartig ist, aber auf einer gewundenen Strecke über seine eigenen Füße stolpert.
- Die „Bottom-Up-Konstrukteure“ (RNGLR & BRNGLR): Diese waren die Champions.
- Sie waren die schnellsten aller „allgemeinen“ Parser.
- Sie waren unglaublich effizient beim Speicherverbrauch und nutzten fast so wenig wie die strengen Roboter.
- Die große Enthüllung: Wenn die Sprache einfach genug für die strengen Roboter war, waren diese neuen „allgemeinen“ Parser nur 3-mal langsamer. Die Autoren argumentieren, dass eine 3-fache Verlangsamung ein geringer Preis dafür ist, jede Sprache handhaben zu können, ohne sie hacken zu müssen.
Die Falle des „Grammatik-Hackens“
Die Arbeit untersuchte auch, was passiert, wenn man eine Sprache „hackt“, um sie passend für die strengen Roboter zu machen.
- Geschwindigkeit: Ja, das Hacken der Sprache, um sie an den strengen Roboter anzupassen, macht sie 4- bis 7-mal schneller.
- Der Haken: Aber das Hacken der Sprache führt oft zum schlechtestmöglichen Szenario für die neuen „allgemeinen“ Parser. Es ist, als würde man die Regeln eines Spiels ändern, nur um dem Lieblingsspieler einen Vorteil zu verschaffen, aber dabei versehentlich das Spiel für alle anderen unspielbar machen.
- Das Urteil: Die Autoren sagen, dass man seine Sprache nicht hacken sollte, nur um ein wenig zusätzliche Geschwindigkeit herauszukitzeln. Die „allgemeinen“ Parser sind für fast alles schnell genug, und das Hacken der Sprache macht die Sprache schwerer lesbar und wartbar.
Das einfache Fazit
Lange Zeit glaubten Softwareentwickler, sie müssten sich zwischen Geschwindigkeit (Verwendung strenger, gehackter Parser) und Flexibilität (Verwendung langsamer, allgemeiner Parser) entscheiden.
Diese Arbeit beweist, dass diese Wahl ein Mythos ist. Die neuen „allgemeinen“ Parser (speziell die GLR-Familie) sind schnell genug, um die Standardwahl zu sein. Sie sind wie ein Universaladapter: Sie passen auf fast jeden Stecker, und obwohl sie vielleicht etwas schwerer sind als ein spezifischer Adapter, ersparen sie einem den Kauf eines anderen Adapters für jedes einzelne Gerät.
Kurz gesagt: Hören Sie auf, Ihre Sprachen zu hacken, damit sie in alte, wählerische Parser passen. Nutzen Sie die neuen, flexiblen „allgemeinen“ Parser. Sie sind schnell, verbrauchen wenig Speicher und lassen Sie Ihre Sprachen so schreiben, wie sie natürlich sein wollen.
Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?
Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.