Compiling Distributed System Models with PGo [evaluation]
Notice bibliographique
Résumé
Distributed systems are difficult to design and implement<br> correctly. In response, both research and industry are exploring<br> applications of formal methods to distributed systems. A key challenge<br> in this domain is the missing link between the formal design of a<br> system and its implementation. Today, practitioners bridge this link through<br> manual effort. We present a language called Modular PlusCal that extends PlusCal by<br> cleanly separating the model of a system from a model of its<br> environment. We then present a compiler tool-chain called PGo that<br> automatically translates MPCal models to TLA+ for model checking,<br> and that also compiles MPCal models to runnable Go code.<br> PGo provides system designers with a new ability to model and check<br> their designs, and then re-use their modeling efforts to<br> mechanically extract runnable implementations of their designs. Our evaluation shows that the PGo approach works for complex models:<br> we model check, compile, and evaluate the performance of MPCal systems<br> based on Raft, CRDTs, and primary-backup.<br> Compared to previous work, PGo requires less time to develop a<br> checked model and derive a fully working implementation. With PGo we<br> created a formally checked Raft model and its corresponding<br> implementation in under 1 person-month, which is 3x less time than<br> Ivy. Our evaluation shows that a PGo-based<br> Raft KV store with three nodes has 41% higher throughput than a Raft<br> KV store based on Ivy, the highest performing verified Raft-based KV<br> store from related work. A PGo-based CRDT set has a latency within 2x of a CRDT set implementation from SoundCloud called<br> Roshi.
Récupéré en direct depuis OpenAlex et désinversé. Les résumés ne sont pas conservés dans cette base de données : les index inversés représentent 8,6 Go des 9,3 Go de texte de la base, et le serveur dispose de 13 Go libres.
Comment cette classification a été obtenuedéplier
Prédiction distillée sur la base complète
Imitation des enseignantsNi prévalence calibrée, ni vérité terrain. Validation humaine à venir. Apprise à partir de 10 348 étiquettes directes de Codex et de 10 348 étiquettes directes de Gemma. Le mode candidate est l'union des têtes enseignantes seuillées; le consensus est leur intersection. Ces sorties portent le statut machine_predicted_unvalidated et ne sont ni des étiquettes humaines ni des étiquettes directes de modèles de pointe.
Scores Codex et Gemma par catégorie
| Catégorie | Codex | Gemma |
|---|---|---|
| Métarecherche | 0,001 | 0,001 |
| Méta-épidémiologie (sens strict) | 0,000 | 0,000 |
| Méta-épidémiologie (sens large) | 0,000 | 0,000 |
| Bibliométrie | 0,001 | 0,001 |
| Études des sciences et des technologies | 0,003 | 0,000 |
| Communication savante | 0,001 | 0,000 |
| Science ouverte | 0,002 | 0,002 |
| Intégrité de la recherche | 0,000 | 0,001 |
| Charge utile insuffisante (le modèle a refusé de juger) | 0,097 | 0,006 |
Scores machine (provisoires)
Les deux têtes enseignantes du modèle étudiant, lues sur ce travail. Un score ordonne la base pour la relecture; il n'affirme jamais une catégorie, et le statut de validation accompagne chaque rangée tel quel.
Scores de référence d'un modèle non mature (critères de maturité non atteints, 7 itérations). Un score ordonne; il n'affirme jamais une catégorie.
score_only:v0-immature-baseline · tel quel depuis la passe de notation : score_only signifie que le nombre peut ordonner les travaux, et qu'aucune étiquette de catégorie n'en découleClassification
machine, non validéePrédiction automatique; les deux têtes enseignantes s’accordent sur ce qui est montré ici.
Le détail, modèle par modèle et score par score, se trouve en fin de page sous « Comment cette classification a été obtenue ».