Je suis très preneur d'un journal sur LLVM orienté JIT !
J'aurais mieux fait de fermer ma gueule :)
Ça viendra, mais faut d'abord que je fasse tout un gros dev avec une vraie bibliothèque de JIT pour comparer proprement. Du coup ça va être long. Le cœur du problème pour les cas que j'ai vu : le code est émis en une seule fois (lourdement), et jamais revu après. Et je suis tombé sur au moins un cas où une phase d'optimisation indispensable pour de bonnes perfs est dans l'étape de codegen, qui n'est pas configurable.
Dans le cas qui m'intéresse, PostgreSQL 11, je suis convaincu de l'utilité du JIT par LLVM pour les grosses requêtes où le gain CPU va exploser le temps de compilation requis, mais je suis certain que ça sera en dessous des performances d'un vrai compilateur à la volée, et même dans certains cas en dessous des performances de PG sans compilation (cf. http://www.postgresql-archive.org/PATCH-LLVM-tuple-deforming-improvements-td6029385.html par exemple). Par contre, une solution bien plus légère de compilation/optimisation progressive du bytecode... ça devrait couvrir cette deuxième partie du spectre.
Je pense que les cas de unladden swallow (interpréteur python utilisant LLVM - http://qinsb.blogspot.com/2011/03/unladen-swallow-retrospective.html) ou encore de webkit (abandon de LLVM pour le JIT - https://webkit.org/blog/5852/introducing-the-b3-jit-compiler/) sont assez clairs. Il est des cas que LLVM couvre excellemment, mais il ne faut absolument pas croire qu'il s'agit là du marteau universel. Ce marteau n'existe pas :)
Les langages dynamiques, l'absence d'optimisation progressive avec retour arrière... ce sont des défis que LLVM ne peut pas relever aujourd'hui. LLVM est conçu avec un modèle complètement statique, parfait pour de nombreux langages. Pour Java, à voir, mais je pense que des choses comme invokeddynamic risquent d'y perdre des plumes.
[^] # Re: Argument fallacieux
Posté par Pinaraf . En réponse au journal quand Oracle fait les affaires de Azul.. Évalué à 10. Dernière modification le 22 août 2018 à 17:31.
J'aurais mieux fait de fermer ma gueule :)
Ça viendra, mais faut d'abord que je fasse tout un gros dev avec une vraie bibliothèque de JIT pour comparer proprement. Du coup ça va être long. Le cœur du problème pour les cas que j'ai vu : le code est émis en une seule fois (lourdement), et jamais revu après. Et je suis tombé sur au moins un cas où une phase d'optimisation indispensable pour de bonnes perfs est dans l'étape de codegen, qui n'est pas configurable.
Dans le cas qui m'intéresse, PostgreSQL 11, je suis convaincu de l'utilité du JIT par LLVM pour les grosses requêtes où le gain CPU va exploser le temps de compilation requis, mais je suis certain que ça sera en dessous des performances d'un vrai compilateur à la volée, et même dans certains cas en dessous des performances de PG sans compilation (cf. http://www.postgresql-archive.org/PATCH-LLVM-tuple-deforming-improvements-td6029385.html par exemple). Par contre, une solution bien plus légère de compilation/optimisation progressive du bytecode... ça devrait couvrir cette deuxième partie du spectre.
Je pense que les cas de unladden swallow (interpréteur python utilisant LLVM - http://qinsb.blogspot.com/2011/03/unladen-swallow-retrospective.html) ou encore de webkit (abandon de LLVM pour le JIT - https://webkit.org/blog/5852/introducing-the-b3-jit-compiler/) sont assez clairs. Il est des cas que LLVM couvre excellemment, mais il ne faut absolument pas croire qu'il s'agit là du marteau universel. Ce marteau n'existe pas :)
Les langages dynamiques, l'absence d'optimisation progressive avec retour arrière... ce sont des défis que LLVM ne peut pas relever aujourd'hui. LLVM est conçu avec un modèle complètement statique, parfait pour de nombreux langages. Pour Java, à voir, mais je pense que des choses comme invokeddynamic risquent d'y perdre des plumes.