[ErgoFast] Improving performance of the SMT solver Alt-Ergo with a better integration of efficient SAT solver
[ErgoFast] Amélioration de performances du solveur SMT Alt-Ergo grâce à l’intégration d’un solveur SAT efficace
Résumé
The automatic SMT (Satisfiability Modulo Theories) solvers are more and more used in the industry and in the academic world. The reason of this success is connected on to the expressiveness of the languages of entrance of these solvers (first order logic with predefined theories), and on their increasing efficiency. The speed of SMT solvers is mainly connected to the decision-making procedures which they implement (SAT solvers, Simplex, etc.). The data structures used and the memory management mechanisms have an immediate impact on the performances. Also, the programming language and the available optimizations of code in the compiler are very important. In the team VALS of the LRI, we develop the SMT solver Alt-Ergo. This tool is programmed with the language OCaml and it is mainly used to prove logical formulas from proof of program workshops as Why3, Spark, Frama-C or the B workshop. His direct competitors are z3 (Microsoft), CVC4 (Univ. New York and Iowa) and yices2 ( SRI). In spite of our efforts in the design and the optimization of the implanted decision-making procedures, it appears that Alt-Ergo is slower than his competitors on certain benchmarks. The reasons are multiple. We identified three important causes. - The first one seems to be connected to the data structures used in the solver. For safety reason, the largest part of Alt-Ergo is developed in a purely functional style of programming with persistent structures. But, the efficiency of these structures is generally worse than imperative structures. - The second seems to be connected to the memory management by the Garbage Collector of the language OCaml, which, compared with a manual management, engenders numerous movements of memory blocks and probably too many cache miss. The difference between cache memory access and RAM access being of the order of 150 clock cycles, the maximal use of the cache memory is very important for the performances. - Finally, the third seems to be connected to the lack of optimizations of the OCaml compiler. Indeed, we noticed that the gap from performance between Alt-Ergo and some of his competitors (written mainly in C or C ++) was strongly reduced when we recompiled them by lowering the compiler optimization level.
Les démonstrateurs automatiques de la famille SMT (Satisfiability Modulo Theories) sont de plus en plus utilisés dans l’industrie et dans le monde académique. La raison de ce succès est liée d’une part à l’expressivité des langages d’entrée de ces solveurs (logique du premier ordre avec de nombreuses théories prédéfinies), et d’autre part, à leur efficacité toujours croissante. La rapidité des solveurs SMT est principalement liée aux procédures de décision qu’ils implémentent (SAT solvers, Simplex, etc.). Ainsi, les structures de données utilisées et les mécanismes de gestion mémoire ont un impact immédiat sur les performances. De même, le langage de programmation utilisé et les optimisations de code disponibles dans le compilateur sont très importants. Dans l’équipe VALS du LRI, nous développons le solveur SMT Alt-Ergo. Cet outil est programmé avec le langage OCaml et il est principalement utilisé pour prouver des formules logiques issues d’ateliers pour la preuve de programme comme Why3, Spark, Frama-C ou l’Atelier B. Ses concurrents directs sont z3 (Microsoft), CVC4 (Univ. New-York et Iowa) et yices2 (SRI). Malgré nos efforts dans la conception et l’optimisation des procédures de décision implantées, il ressort qu’Alt-Ergo est plus lent que ses concurrents sur certaines suites d’essais. Les raisons à cela sont multiples. Nous avons identifié trois causes importantes. — La première semble être liée aux structures de données utilisées dans le solveur. Pour des rai- sons de sûreté, la plus grande partie d’Alt-Ergo est développée dans un style de programmation purement fonctionnel avec des structures persistantes. Mais, l’efficacité de ces structures est en général moins bonne que des structures impératives. — La deuxième semble être liée à la gestion mémoire par ramasse-miettes du langage OCaml qui, comparée à une gestion manuelle, engendre de nombreux déplacements de blocs mémoire et probablement trop de défauts de cache. La différence entre un accès à la mémoire cache d’un ordinateur et un accès à la RAM étant de l’ordre de 150 cycles d’horloge, l’utilisation maximale de la mémoire cache est très importante pour les performances. — Enfin, la troisième semble être liée au manque d’optimisations du compilateur OCaml. En effet, nous avons constaté que l’écart de performance entre Alt-Ergo et certains de ses concurrents (écrits principalement en C ou C++) était fortement réduit lorsque l’on re-compilait ces derniers en baissant le niveau d’optimisation du compilateur.
Domaines
Informatique et langage [cs.CL]| Origine | Version validée par le jury (STAR) |
|---|
Loading...