On 2015-12-31 11:23:35 +0100, Basile Starynkevitch wrote: > Oui et non. C'est vrai que GMP -voir http://gmplib.org/ pour les détails- > utilise du code assembleur (notamment parce que les instructions machine > d'addition avec retenue très utiles en arithmetique double précision ne sont
multiprécision (avec des entiers), pas double précision (qui fait référence à un format virgule flottante). > pas accessibles en C99, mais GCC fournit > https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html & > https://gcc.gnu.org/onlinedocs/gcc/x86-Built-in-Functions.html ...) En fait, le problème est probablement que GCC ne sait pas bien optimiser certains codes. Soit on a le code assembleur en tête, et autant écrire directement en assembleur (on est sûr que le compilateur ne "désoptimise" pas de l'assembleur qui serait retranscrit en C), soit on écrit du code C de manière un peu arbitraire pour tous les processeurs, et une optimisation demanderait des transformations non triviales pour certains processeurs. Si quelqu'un veut essayer du code C semi-générique, i.e. C avec builtins de GCC, et comparer avec le code assembleur... > mais la très grosse majorité de GMP est codée en C, pas en > assembleur. C'est normal: GMP est écrit par couches. J'aurais peut-être dû préciser: la couche basse (mpn) de GMP. Cela fait tout de même pas mal de fonctions. C'est non négligeable. > Seul le sous repertoire mpn/x86_64 visible en > https://gmplib.org/repo/gmp-6.1/file/tip/mpn/x86_64 du code source > de GMP contient des fichiers assembleurs (pour x86-64). Idem pour chaque processeur (parfois il n'existe que le code générique en C, mais c'est normalement du C ISO, sans builtins). Et note que pour chaque architecture (e.g. x86_64), il y a du code spécifique pour chaque sous-architecture (environ une dizaine pour x86_64). Au total, ça fait beaucoup de code assembleur! > Je n'ai pas fait le compte des lignes de code dans GMP, mais il me semble > bien que sur une machine donnée, les trois quarts au moins du code binaire > d'une librarie libgmp.so proviennent de fichiers C, pas de fichiers > assembleurs. Peut-être, mais si tu fais le total pour toutes les machines, le code assembleur devient important. Un ordre d'idée pour GMP 6.1.0: cventin% ls **/*.asm(.) | wc -l 772 cventin% ls **/*.c(.) | wc -l 831 cventin% cat **/*.asm(.) | wc 136918 513735 3081440 cventin% cat **/*.c(.) | wc 145071 571333 3878004 Si on se restreint à la couche mpn: cventin% ls **/*.asm(.) | wc -l 759 cventin% ls **/*.c(.) | wc -l 223 cventin% cat **/*.asm(.) | wc 136016 509834 3055279 cventin% cat **/*.c(.) | wc 39091 178321 1117751 Mais plus que la proportion par rapport au C, c'est plutôt en nombre de lignes de code assembleur que c'est important: 136k. > Bonne année à tous. Bonne année, -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)