Quatre distributions, deux compilateurs.
Debian 12, Ubuntu 24.04, Fedora 44 et Alpine 3.24 passent la compilation et les exemples calculator/ticket avec GCC et Clang, dans des VM jetables utilisant leurs propres noyaux.
RUG, analysé.
Trois contributions ciblées.
Un générateur de parseurs C++98.
Trois contributions documentées.
LE PROJET / RUG
Une grammaire ABNF.
Un parseur d’octets.
RUG — Rug Understands Grammar — compile l’ABNF en tables LALR(1) compactées. Son image immuable est partageable entre sessions de parsing incrémental, avec callbacks sémantiques et contrôle explicite de la mémoire de travail.
- Dépôt d’origine
- roman-starcevic/RUG
C++98 · Apache-2.0 - Révision de référence
fe40fab82c61a6fdd95fa49162a289e703644f1c
Tous les candidats de performance ont été mesurés face à cette révision non modifiée.- État de revue
- 3 PR soumises · 0 fusionnées dans cet instantané
L’AUDIT INITIAL
Compiler, parser,
tester les limites.
La portabilité et la robustesse ont été examinées avant de proposer des changements. Ces contrôles décrivent l’audit de référence, pas une nouvelle campagne sur quatre distributions pour le code optimisé.
Exercer les entrées invalides et incrémentales.
Dix configurations locales et 60 contrôles déterministes ASan/UBSan passent. Les campagnes bornées de fuzzing grammaire et runtime ont réalisé 44 476 et 48 605 exécutions sans défaut sanitizer confirmé. Ce n’est pas une preuve de sûreté.
LES CONTRIBUTIONS EN AMONT
Un correctif.
Deux optimisations indépendantes.
Chaque PR contient son changement et ses tests. Les PR de performance incluent aussi les paires mesurées et des scripts de reproduction autonomes.
| Contribution | Ce qui change | PR | Statut |
|---|---|---|---|
Diagnostics structurés des grammaires | Rejeter les grammaires vides ou composées de commentaires via RugBuildError, au lieu d’une logic_error qui échappe aux appelants interceptant le type documenté. | #1 | Ouverte |
Recherche dans les tables compactées | Résoudre les adresses immuables des sections ACTION/GOTO/règles une fois par recherche, en évitant les appels répétés aux accesseurs. | #2 | Ouverte |
Comptage des actions par défaut | Remplacer le recomptage quadratique des 257 actions par des fréquences puis une sélection ordonnée, en conservant le départage. | #3 | Ouverte |
Instantané des statuts : 2026-10-23 UTC. Consulter chaque PR pour la discussion actuelle ; soumis ne signifie pas accepté.
LES RÉSULTATS MESURÉS
Moins de travail dans le parseur.
Moins de travail pour le construire.
Deux expériences avant/après séparées, sur la même machine et avec le même compilateur. Leurs gains ne doivent pas être multipliés ni présentés comme un résultat cumulé.
PARSING / 18 CAS
20,6–37,0 %De temps de parsing/reset en moins
Sur six charges et trois tailles de blocs. Dix paires par cas, après échauffement.
Méthode et paires brutesCONSTRUCTION / 6 GRAMMAIRES
15,9–31,1×Construction à chaud plus rapide
Construction/destruction complète et répétée de Rug. Les images runtime des six grammaires sont identiques octet par octet.
Méthode et paires brutesRyzen 9 3900X · GCC 16.2.1 · C++98 · -O2 -g -fno-omit-frame-pointer · sans LTO. Ce sont des observations propres à ces charges, pas des gains universels ou des résultats intégrés en amont.
LES MESURES EN DÉTAIL
Les mêmes charges.
Une comparaison reproductible.
Le parsing ci-dessous utilise des blocs de 4 096 octets ; le rapport contient les trois tailles. La construction correspond à un build complet. Les ratios utilisent les médianes appariées.
| Charge | Baisse du temps de parsing | Build de référence | Build optimisé | Facteur de construction |
|---|---|---|---|---|
tiny | 23,6 % | 0,944 ms | 0,033 ms | 28,53× |
medium | 25,9 % | 15,726 ms | 0,506 ms | 31,05× |
large | 25,9 % | 61,787 ms | 2,242 ms | 27,57× |
binary | 21,1 % | 61,323 ms | 2,535 ms | 24,13× |
calculator | 37,0 % | 21,855 ms | 1,372 ms | 15,87× |
ticket | 33,0 % | 31,989 ms | 1,390 ms | 22,92× |
Les colonnes de parsing et de construction décrivent des changements isolés différents, pas un même binaire combiné.
LES OUTILS / LEUR RÔLE RÉEL
Observer le coût.
Valider l’hypothèse.
La démarche suit la caractérisation de charge, un écran USE partiel, le profilage CPU et les expériences contrôlées, inspirés des méthodes publiques de Brendan Gregg.
Les profils, puis les compteurs.
Une version locale d’omn 0.1.0 a identifié le coût des recherches/accesseurs et de construction des tables. Cinq paires PMU observent 26,5 % d’instructions retirées en moins pour le parsing et 96,8 % pour la construction, sur des charges fixes. L’analyse du code a conduit aux patches ; l’outil n’a pas optimisé le code automatiquement.
Préciser le rôle de chaque outil.
distroproof a fourni la matrice de VM de référence. ATFQ a fourni du contexte mémoire, xpac a lu l’inventaire des paquets ; aucun n’a profilé RUG. VMAnyware n’a pas été utilisé. Les modes USE/latence BPF complets d’Omniscient ont refusé les permissions manquantes ; les sources CPU utilisateur disponibles ont été utilisées.
VALIDATION ET LIMITES
Les preuves ont un périmètre.
Les résultats aussi.
Les deux candidats passent les builds GCC et Clang ASan/UBSan, les oracles indépendants, les exemples et les traces incrémentales différentielles. Les optimisations n’ont pas été retestées sur les quatre distributions, avec LTO ou sur un autre matériel.
- Contrôles fonctionnels
- 4 626 résultats ACTION/GOTO par oracle ; 300 lignes d’actions par défaut dont les égalités ; images identiques pour six grammaires ; callbacks, spans d’erreur et reset/réutilisation.
- Limites de mesure
- Les cibles étaient fixées sur un CPU, mais fréquence et température n’étaient pas verrouillées. Les comptes PMU finaux sont en mode utilisateur, sans multiplexage. Aucun échantillon perdu signalé ; le coût du collecteur exclut une partie du coût dans la cible.
- Compromis
- L’histogramme de construction ajoute des allocations temporaires de map, bornées par 257 clés par ligne. Aucun gain mémoire, garantie de sécurité ou approbation du mainteneur n’est revendiqué.
RAPPORTS ET REPRODUCTION
Lire l’analyse.
Reproduire les mesures.
Télécharger le rapport, examiner les données ou suivre les instructions de reproduction indépendantes de chaque PR de performance.
Contribution indépendante de moha-bekh. Le statut des PR est l’instantané daté ci-dessus ; aucune approbation du mainteneur de RUG n’est sous-entendue.