Le JIT expérimental (JitIL) était effectivement une tentative de rendre le code recompilé plus rapide en passant par une layer intermédiare : au lieu de faire PPC -> X86 directement, on fait PPC -> IL -> X86, avec potentiellement des passes d'optimisation sur l'IL. Le problème c'est que la plupart des passes d'optimisation à faire sur l'IL ne sont pas triviales du tout à réaliser en gardant un comportement identique au code PPC original (à l'exception de quelques trucs basiques comme les peephole opts qui sont de toute façon déjà implémentée dans JIT64, le JIT par défaut). Du coup, JitIL n'a jamais vraiment été plus rapide que JIT64 - en x86 parfois il est un peu plus rapide car l'allocateur de registres est un peu plus intelligent (en x86_64 plus de registres sont dispos donc ça se voit moins).
Je pense que c'est une approche intéressante, mais sans réutiliser un backend d'optimisation commun à la LLVM ça risque de ne jamais vraiment aboutir. Le problème de LLVM pour un JIT dynamique comme celui là c'est que LLVM gère très mal l'invalidation de code JITé (en gros, on doit invalider tout le module et recompiler toutes les fonctions qui ont des branches statiques vers une fonction invalidée) comparé à ce qu'on peut faire à la main (juste remplacer comme un bourrin le code de l'ancienne fonction par la nouvelle). Si quelqu'un cherche un sujet de recherche intéressant, un backend "à la LLVM" de JIT pour l'émulation ça me semble être une idée à explorer.
[^] # Re: Dolphin, etc.
Posté par Pierre Bourdon . En réponse au journal Les jeux de BigN sous Linux. Évalué à 4.
Le JIT expérimental (JitIL) était effectivement une tentative de rendre le code recompilé plus rapide en passant par une layer intermédiare : au lieu de faire PPC -> X86 directement, on fait PPC -> IL -> X86, avec potentiellement des passes d'optimisation sur l'IL. Le problème c'est que la plupart des passes d'optimisation à faire sur l'IL ne sont pas triviales du tout à réaliser en gardant un comportement identique au code PPC original (à l'exception de quelques trucs basiques comme les peephole opts qui sont de toute façon déjà implémentée dans JIT64, le JIT par défaut). Du coup, JitIL n'a jamais vraiment été plus rapide que JIT64 - en x86 parfois il est un peu plus rapide car l'allocateur de registres est un peu plus intelligent (en x86_64 plus de registres sont dispos donc ça se voit moins).
Je pense que c'est une approche intéressante, mais sans réutiliser un backend d'optimisation commun à la LLVM ça risque de ne jamais vraiment aboutir. Le problème de LLVM pour un JIT dynamique comme celui là c'est que LLVM gère très mal l'invalidation de code JITé (en gros, on doit invalider tout le module et recompiler toutes les fonctions qui ont des branches statiques vers une fonction invalidée) comparé à ce qu'on peut faire à la main (juste remplacer comme un bourrin le code de l'ancienne fonction par la nouvelle). Si quelqu'un cherche un sujet de recherche intéressant, un backend "à la LLVM" de JIT pour l'émulation ça me semble être une idée à explorer.