Options GCC pour compiler un noyau optimisé.

Lunix64 · 18-09-2020 07:05:35

Bonjour à tous,

J'ai compilé un noyau pour Buster avec les options: -O3 -march=native -mtune=native

Le système me parait plus réactif avec ce noyau. Mais j'ai vérifié à quoi correspondait le "native", avec les commandes:

gcc -march=native -Q --help=target|grep march

et

gcc -march=native -mtune=native -Q --help=target|grep mtune

Et voilà le résultat pour mon processeur apollo lake (nom de code goldmont):
-march: skylake
-mtune: generic

Malgrès ça, le noyau semble fonctionner. Apparemment ma version de gcc ne gère pas encore les goldmont. Mais sur le site web de gcc il y a de grosses différences entre un skylake et un goldmont:

‘skylake’

Intel Skylake CPU with 64-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, AVX, AVX2, AES, PCLMUL, FSGSBASE, RDRND, FMA, BMI, BMI2, F16C, RDSEED, ADCX, PREFETCHW, CLFLUSHOPT, XSAVEC and XSAVES instruction set support.

et:

‘goldmont’

Intel Goldmont CPU with 64-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, AES, PCLMUL, RDRND, XSAVE, XSAVEOPT and FSGSBASE instruction set support.

Donc, je me demande si il y a un moyen de donner à GCC les options goldmont sans utiliser les -march et -mtune ? EDIT: je viens de lire sur la page des option gcc qu'il fallait passer les options de la façon suivante: -m suivit du nom de l'instruction par exemple: "-mmmx -mmovbe -msse".

Mais je me demande aussi si le -march=native et -mtune=native fonctionnent correctement ?

Sinon, comme j'ai un autre pc à optimiser, je me demande où sur internet trouver la liste des instructions supportées par un microprocesseur ?

Dernière modification par Lunix64 (18-09-2020 07:28:35)

--gilles-- · 18-09-2020 08:05:12

Lunix64 a écrit :

Bonjour à tous,

J'ai compilé un noyau pour Buster avec les options: -O3 -march=native -mtune=native

Le système me parait plus réactif avec ce noyau. Mais j'ai vérifié à quoi correspondait le "native", avec les commandes:
gcc -march=native -Q --help=target|grep march

et
gcc -march=native -mtune=native -Q --help=target|grep mtune

Et voilà le résultat pour mon processeur apollo lake (nom de code goldmont):
-march: skylake
-mtune: generic

Malgrès ça, le noyau semble fonctionner. Apparemment ma version de gcc ne gère pas encore les goldmont. Mais sur le site web de gcc il y a de grosses différences entre un skylake et un goldmont:
‘skylake’

Intel Skylake CPU with 64-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, AVX, AVX2, AES, PCLMUL, FSGSBASE, RDRND, FMA, BMI, BMI2, F16C, RDSEED, ADCX, PREFETCHW, CLFLUSHOPT, XSAVEC and XSAVES instruction set support.

et:
‘goldmont’

Intel Goldmont CPU with 64-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, AES, PCLMUL, RDRND, XSAVE, XSAVEOPT and FSGSBASE instruction set support.

Donc, je me demande si il y a un moyen de donner à GCC les options goldmont sans utiliser les -march et -mtune ? EDIT: je viens de lire sur la page des option gcc qu'il fallait passer les options de la façon suivante: -m suivit du nom de l'instruction par exemple: "-mmmx -mmovbe -msse".

Mais je me demande aussi si le -march=native et -mtune=native fonctionnent correctement ?

Sinon, comme j'ai un autre pc à optimiser, je me demande où sur internet trouver la liste des instructions supportées par un microprocesseur ?

Essaye de voir ici :

https://www.intel.fr/content/www/fr/fr/ … =title:asc

Lunix64 · 18-09-2020 10:39:28

Merci pour le lien, mais je n'ai pas trouvé la liste des jeux d'instructions supportés. Par contre je viens de trouver le site cpu-world.com qui donne la liste des jeux d'instructions supportés par les microprocesseurs, dans la section nommée "Supported instructions".

Les pages qui m'intéressent sont: Pentium N4200 et celeron 900

Les jeux d'instructions qui sont listés sur le site ne sont pas en option sur la page web de gcc, ni en ligne de commande gcc. Par exemple le "cmov", j'ai pas vu d'option gcc "-mcmov".

Est-ce que ça veut dire que gcc ne peut pas utiliser ces jeux d'instruction ?

naguam · 18-09-2020 11:24:44

Lunix64 a écrit :

Malgrès ça, le noyau semble fonctionner. Apparemment ma version de gcc ne gère pas encore les goldmont. Mais sur le site web de gcc il y a de grosses différences entre un skylake et un goldmont:

Quelle est ta version de gcc ?
Aussi la majorité des processeur intel sortis post-skylake sont des dérivés du skylake donc après c'est normal qu'il detecte skylake si il ne supporte pas les cpu plus recents.
C'est déjà plus optimisé que l'optimisation march=x86_64 qui se base sur les premiers x86_64 pour rester générique et avoir des binaires compatible avec tous les cpu x86_64.
L'intérêt du générique cependant c'est d'être compatible avec tous cpu x86_64 et si tu veux changer le disque de la machine pour une machine différente (genre opti skylake sur ryzen......) c'est pas forcement stable de ne pas être générique et ça peut crasher voir juste pas fonctionner.

Tu peux dire à gcc d'utiliser des instructions en particulier également, la doc gcc les listes toutes (après faut connaitre ta version de gcc pour savoir quelles optimisations cpu sont supportées par ta version)
D'ailleurs tu n'es pas obligé de mettre -march=native si tu trouves que la détection ne te correspond pas, tu peux directement mettre -march=goldmont (si supporté par le compilo).

Aussi par curiosité comment lances-tu la compil du kernel avec les options, tu modifie les makefiles ou tu ajoute les args ?
En fait dans tout les cas je te conseilles de faire un diff entre le binaire d'un kernel linux build avec ou sans tes optimisations avec les memes sources et la meme config sans rien toucher.
En théorie tu ne devrais pas avoir de différences en arg (et potentiel crash si on modifie les sources hors connaissances avancées de cause) car le kernel normalement n’interprètes pas tes optimisations que tu pourrais lui donner en arg et cet article explique mieux que moi le pourquoi sans patch (qui n'ont pas étés accepté en upstream) pourquoi on ne compile pas un kernel linux avec ce genre d'optimisation (histoires notamment de stabilitée et de maintenabilité).

D'ailleurs tout ce que je dis dans ce post on parle d'optimisation cpu mais pas que, des optimisation aussi juste du compilo pour optimiser les sorties ou la vitesse de traitement comme -Ofast entre autres et tout un tas d'autres.

Le kernel gère la mémoire, de tous les trucs en espace noyau: tout un tas de choses bas niveau et critiques, et faire certaines options d'optimisation spéciques et non génériques ont beaucoup plus de possibilités d'impact indésirables qu'on pourrait penser, les options par default dans les makefiles des sources sont choisis avec grand soins.
Sur un programme destiné à tourner en espace utilisateur c'est déjà moins risqué ni problématique et c'est un peu ce que permet gentoo principalement (et les devs gentoo font aussi de recommendations et des gros warnings sur les optimisations et choisissent souvent de faire leurs patchs touchant à ce genre de chose avec grand soin également pour éviter les problèmes).

Pour conclure appliquer des optimisation c'est pas "yes je vais gagner beaucoup de perf et c'est sans conséquences...". Il y a des impacts en fonction du types d'optimisation à prendre en compte, voir https://wiki.gentoo.org/wiki/GCC_optimization

Dernière modification par naguam (18-09-2020 12:05:04)

Lunix64 · 18-09-2020 19:29:13

naguam a écrit :

Quelle est ta version de gcc ?

La 8.3, celle de Buster.

naguam a écrit :

Aussi par curiosité comment lances-tu la compil du kernel avec les options, tu modifie les makefiles ou tu ajoute les args

J'ai modifé le makefile à la racine du dossier du noyau. C'est un kernel 5.8.4, J'ai remplacé l'option "-O2" par "-O3 -march=native -mtune=native".
Makefile d'origine, la deuxième ligne:

ifdef CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE

KBUILD_CFLAGS += -O2

else ifdef CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE_O3

KBUILD_CFLAGS += -O3

else ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE

KBUILD_CFLAGS += -Os

endif

Makefile modifié, seulement la deuxième ligne, à la place de -O2:

ifdef CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE

KBUILD_CFLAGS += -O3 -march=native -mtune=native

else ifdef CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE_O3

KBUILD_CFLAGS += -O3

else ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE

KBUILD_CFLAGS += -Os

endif

naguam a écrit :

Pour conclure appliquer des optimisation c'est pas "yes je vais gagner beaucoup de perf et c'est sans conséquences...". Il y a des impacts en fonction du types d'optimisation à prendre en compte

OK, merci pour toutes ces infos. Du coup je me dit qu'un -O3 est peut-être pas une bonne idée, mais les optimisations basées sur les instructions spécifiques à un processeur ?

En fait, je voit pas trop l'intérêt de faire des processeurs avec des instructions spécifiques qui sont sensées accélérer les logiciels, si ni le noyau, ni les logiciels, ne les utilisent. Pour moi, c'est au moins le noyau qui doit les utiliser, les logiciels eux font en général des appels systèmes au noyau et pour le reste, c'est mieux qu'ils les utilisent, mais pour ça il faut avoir leur code source et qu'il soit compilable sur la machine.

J'ai aussi essayé de compiler gnu icecat avec les mêmes optimisations, résultat: j'ai une librairie .so de 2 Giga, et des erreurs qui s'affichent dans le terminal, mais icecat semble fonctionner quand même. En tout cas, ces erreurs et cet librairie de 2 Giga, ça ne me met pas en confiance pour utiliser le logiciel.

Par contre pour le noyau, compiler avec les optimisations ne m'a jamais posé de problèmes sauf une fois avec un vieux kernel: un warning dans le pilote AMDGPU sur la longueur d'une chaine de carractère, j'ai corrigé le code source, et plus de warning. Le warning n'apparaissait qu'avec -O3, pas en -O2.

naguam · 18-09-2020 20:49:47

Lunix64 c'est pas parce que tu n'optimises pas le kernel via les options de compilations que ça l'empêche d'utiliser les instructions spécifiques, juste elle ne seront pas utilisées en auto dans les parties n'utilisant originellement pas ces instructions au moment de la compilation. Idem pour les programmes en espace utilisateur, tu peux utiliser des instructions spécifiques, spécifiées par le programmeur via des librairies adaptées; ou meme des mecanismes implémentés via des syscall ou encore en assembleur directement à la main sans utiliser les optimisations.
Après si avec ton kernel optimisé tu n'a pas de problème de stabilité ni de perfs sur certains points (car une optimisation aussi etre une perte plus qu'un gain dans certains cas de figure) tant mieux mais je penses que si le kernel utilise des optimisations précises et que c'est pas prévu spécialement d'utiliser certains optimisations du compilateur.. voilà. Encore une fois je radote mais les optimisations ne n'est pas que du sans risque, faut pas vouloir utiliser toutes les nouvelles instructions à tord et à travers pour gagner en performance, faut les utiliser quand c'est intéressant.

Aussi c'est pas parce que un kernel n'utilise pas l'optimisation cpu que tes programmes ne peuvent pas les utiliser sur un même système.

Et pour le kernel c'est même à une autre dimension car il est mis a jour pour supporter le matériel donc les nouveaux processeurs et donc detecte (enfin plutôt ellse sont spécifiées dans les sources) les nouvelles instructions et peut les utiliser si voulu.

En plus les optimisations généralement la plupart du temps n'apportent pas forcement un gain réellement mesurable.

Après ce que je dis n'est pas une règle, souvent les developpeurs d'un projet utilisent volontairement des optimisations en plus de faire le code adapté. Mais je fais confiance au développeur de spécifier des options qui ont étés choisies avec connaissance du code et de l'impact sur celui-ci et du projet en général.

Pour finir la meilleure optimisation c'est qu'au lieu de toujours utiliser plus d'optimisations de compilation sur du mauvais code, de faire du code correct, plus performant déjà dans le design.
Utiliser des instructions vectorielles pour faire un strlen en C c'est un peu idiot sauf algorythme apportant un reel gain utilisant les instructions (le compilo va pas mettre l'ago tout seul) et encore.
En revanche utiliser ces instructions pour des calculs sur des nombres à virgules et tout un tas de choses pour lequelles c'est adapté.

Egalement utiliser un algorithme adapté avec la bonne structure de donnée éviter les pratiques qui font ralentir le code donne plus de gain qu'une optimisation du compilateur.

Autre point de vue:
binaire optimisé via les opti cpu:
- 5% + performant que le normal (à la louche)
- mais pas portable
binaire normal
- moins performant que l'opti
- mais portable

C'est peut être un poil différent pour le kernel mais c'est plus tellement une histoire de perf mais une histoire de stabilité en plus de la portabilité.

En sachant que dans 90% des cas dans les distributions sont prépackagées et c'est donc la portabilité qui prime.

Dernière modification par naguam (18-09-2020 22:01:07)

Debian-facile

#1 18-09-2020 07:05:35

Options GCC pour compiler un noyau optimisé.

#2 18-09-2020 08:05:12

Re : Options GCC pour compiler un noyau optimisé.

#3 18-09-2020 10:39:28

Re : Options GCC pour compiler un noyau optimisé.

#4 18-09-2020 11:24:44

Re : Options GCC pour compiler un noyau optimisé.

#5 18-09-2020 19:29:13

Re : Options GCC pour compiler un noyau optimisé.

#6 18-09-2020 20:49:47

Re : Options GCC pour compiler un noyau optimisé.

Pied de page des forums