COMPTOIR
  
register

Lancer des optimisations poussées du compilateur sur le noyau Linux : à quoi bon ?

Il y a une semaine, une proposition émergeait de la communauté maintenant le noyau Linux : pourquoi ne pas le compiler par défaut en utilisant l’option — O3, entraînant l’activation des optimisations avancées lors de la traduction du code C en assembleur compris par le CPU. Si la chose a été refusée par le guru-créateur du projet, Linus Torvalds, dans un mail surprenamment courtois et argumenté — l’option ayant déjà entraîné des pertes de performances dans le passé, et l’activation manuelle est très aisée pour qui voudrait s’y risquer — cela n’empêche pas de se poser la question, notamment chez notre confrère Phoronix, toujours là pour lancer du bench et vérifier les hypothèses émergeant sur la toile.

 

Aux commandes, un i5 12600K propulsé par un Ubuntu 22.04 utilisant la dernière version 5.19 du noyal, compilée avec les options par défaut contre un — O3 rajouté ; et strictement les mêmes binaires pour ce qui est des applications testées. Le test est composé de 230 benchmarks différents : largement de quoi voir où les optimisations sont bénéfiques… ou non !

 

 

 
Avec moins de 2 % de différence en moyenne géométrique sur la suite de test, force est de constater que l’option ne fait pas de miracles, d’autant plus que le switch de contexte bouscule ce chiffre vers le haut avec une accélération d’un facteur 3, mais à quel prix (cela pue la désactivation de code jugé « non essentiel » mais pourtant utile à la sécurité des machines), et pour quels gains en pratique ? Pour le reste, les tâches sur bases de données se voient un peu plus rapides, tout comme certains traitements réseau, sans plus. Au moins, aucune des applications n’a été ralentie : ouf ! Cependant, il faudrait vérifier avec d’autres processeurs et jeu d’instruction pour se faire un avis définitif sur la question ; mais en ce qui concerne Alder Lake, la chose est claire : sassertàrien !
 
 
linux
Un poil avant ?

Half-Life 2 peut tourner sur Switch... avec une bonne dose de bidouille

Un peu plus tard ...

Premier pilote Radeon de juin fin juin !

Les 7 ragots
Les ragots sont actuellement
ouverts à tous, c'est open bar !
par Skwal en Auvergne-Rhône-Alpes, le Mardi 19 Juillet 2022 à 07h01  
Bonjour,

Personnellement j'utilisais Gentoo puis Calculate Linux, plus facile, et ai recompilé tout le système avec -O3...

Et bien je peux vous dire que pour moi la différence est clairement là !
La rapidité avec laquelle le système et les programmes se lancent est incroyable. (4 secondes pour éteindre le système, par exemple).
Pour le moment aucune erreur de compilation malgré les 1660 paquets installés et aucun problème en vue.

Ma config:

OS: Calculate Linux Desktop 22.0.1 KDE x86_64
Kernel: 5.15.29-calculate
Uptime: 12 hours, 11 mins
Packages: 1660 (emerge)
Shell: zsh 5.8.1
Resolution: 1920x1080
DE: Plasma 5.24.5
WM: kwin
Theme: Adwaita [GTK3]
Icons: breeze-dark [GTK2], Adwaita [GTK3]
Terminal: konsole
CPU: AMD Ryzen 7 3700X (16) @ 4.050GHz
GPU: NVIDIA GeForce GTX 1050
Memory: 4425MiB / 15988MiB

Merci pour l'article, bonne continuation !
Cordialement, Skwal.
par Un #vieuxkon en Île-de-France, le Dimanche 03 Juillet 2022 à 06h31  
par Un champion du monde en Auvergne-Rhône-Alpes, le Vendredi 01 Juillet 2022 à 09h27
Mwé, utiliser du O3 sur le kernel même si le code est propre c'est risquer de se retrouver avec des problèmes difficiles à dépanner pour au final pas gagner des masses de performance :
En théorie, un OS est supposé être optimisé le plus possible... le problème principal ici est relatif aux failles de sécurité des processeurs, qui disqualifient forcément certaines "optimisations".
par shrd, le Vendredi 01 Juillet 2022 à 20h46  
par Un ragoteur sans nom embusqué, le Vendredi 01 Juillet 2022 à 10h18
Probablement que ça aurait plus d'intérêt sur l'appli en elle-même, plutôt que sur l'OS.
exact, pour bencher un OS il faut lancer des millions de scripts identiques et voir si il y a une différence ou le temps de boot (meme le temps de mise a jour de l'OS c'est le decompresseur de paquets qu'il faudrait mettre en O3 pour voir une différence). sur une seule appli identique, a moins d appels systèmes incessant, aucun gaib
par Un ragoteur sans nom embusqué, le Vendredi 01 Juillet 2022 à 10h18  
Probablement que ça aurait plus d'intérêt sur l'appli en elle-même, plutôt que sur l'OS.
par Cronff, le Vendredi 01 Juillet 2022 à 10h09  
Les optimisations sont surtout visibles sur des cibles bien moins perfs qu'un i5 12600K.
C'est plus pertinant en embarqué par exemple.

Par contre oui, pour débourrer du code, même en O2 c'est parfois compliqué et il faut recompiler sans optim, voir en -g
par Nicolas D., le Vendredi 01 Juillet 2022 à 09h52  
par Un champion du monde en Auvergne-Rhône-Alpes, le Vendredi 01 Juillet 2022 à 09h27
Mwé, utiliser du O3 sur le kernel même si le code est propre c'est risquer de se retrouver avec des problèmes difficiles à dépanner pour au final pas gagner des masses de performance :
Si c'est pour détecter les bugs, rien n'empêche de tourner en -O2 ou moins, par contre si le bug est causé par un optimisation spécifique du -O3, ça...
par Un champion du monde en Auvergne-Rhône-Alpes, le Vendredi 01 Juillet 2022 à 09h27  
Mwé, utiliser du O3 sur le kernel même si le code est propre c'est risquer de se retrouver avec des problèmes difficiles à dépanner pour au final pas gagner des masses de performance :