J'ai déjà lu ça, mais ce qui m'intéresse, c'est de voir comment se débrouille mon LLVMC qui est quand-même intéressant du fait qu'il n'optimise qu'une seule fois (la compilation est extrêmement rapide, ça défile aussi vite qu'un simple sed un peu recherché).
Le fait que l'optimisation soit faite sur le bytecode final permet de mieux optimiser, d'inliner des fonctions, de propager des constantes, etc. Le LTO, ça marche vraiment, même si on se dit que ça ne sert que dans peu de cas.
Exemple, j'ai dans Setup une fonction nommée matchVersion, qui vérifie qu'une version correspond à une autre comme on veut (en clair, si on lui passe "1.3.4", >=, "1.3.0", elle retourne true). Le truc que j'envoie au milieu est un simple INT, représentant l'opération.
Une partie de mon écriveur de base de donnée s'occupe de rechercher une version exacte. Il envoie donc toujours DEPEND_OP_EQ (le ==). Problème, sans LTO, matchVersion est dans un autre fichier.
Avec LTO, LLVM me détecte que j'envoie une valeur immédiate. Il va alors m'inliner cette fonction, me retirer les ifs qu'il y a dedans, retirer la fonction que je n'appelle donc pas, supprimer une variable inutilisée, inliner une autre fonction dedans, en appliquant le même traitement.
Finalement, un «setup update» passe de 1,2 secondes à 0,8. Pas mal non ?
Alors oui, Clang supporte l'option -O4 qui fait aussi du LTO .. uniquement sur Darwin. En effet, le toolchain Clang sous Linux est encore minimal (en gros : passer le plus vite possible en ELF et appeler les outils de GCC), le gain est donc minimal. Mon LLVMC reste le plus longtemps en bitcode LLVM, et compare donc bien mieux les différences entre GCC et LLVM.
[^] # Re: Bench entre GCC et LLVM
Posté par steckdenis . En réponse au journal Clang++ est prêt. Évalué à 3.
Le fait que l'optimisation soit faite sur le bytecode final permet de mieux optimiser, d'inliner des fonctions, de propager des constantes, etc. Le LTO, ça marche vraiment, même si on se dit que ça ne sert que dans peu de cas.
Exemple, j'ai dans Setup une fonction nommée matchVersion, qui vérifie qu'une version correspond à une autre comme on veut (en clair, si on lui passe "1.3.4", >=, "1.3.0", elle retourne true). Le truc que j'envoie au milieu est un simple INT, représentant l'opération.
Une partie de mon écriveur de base de donnée s'occupe de rechercher une version exacte. Il envoie donc toujours DEPEND_OP_EQ (le ==). Problème, sans LTO, matchVersion est dans un autre fichier.
Avec LTO, LLVM me détecte que j'envoie une valeur immédiate. Il va alors m'inliner cette fonction, me retirer les ifs qu'il y a dedans, retirer la fonction que je n'appelle donc pas, supprimer une variable inutilisée, inliner une autre fonction dedans, en appliquant le même traitement.
Finalement, un «setup update» passe de 1,2 secondes à 0,8. Pas mal non ?
Alors oui, Clang supporte l'option -O4 qui fait aussi du LTO .. uniquement sur Darwin. En effet, le toolchain Clang sous Linux est encore minimal (en gros : passer le plus vite possible en ELF et appeler les outils de GCC), le gain est donc minimal. Mon LLVMC reste le plus longtemps en bitcode LLVM, et compare donc bien mieux les différences entre GCC et LLVM.