COMPTOIR
  
register

Composé par ————— —— 14879 vues

Quel compilo utiliser pour tirer le meilleur de son CPU ?

Si vous êtes dans le domaine de la programmation, plus précisément en C/C++/Rust/…, alors vous êtes conscient qu’un compilateur est nécessaire pour faire fonctionner le bousin sur une machine afin de traduire le code source en assembleur compréhensible par le CPU. Or, ce composant est crucial au niveau des performances des programmes ainsi générés, ce pourquoi moult firmes s’étaient jadis aventurées dans le segment : Codeplay, Borland, PGI… Désormais, seule une poignée de contestants demeurent : GCC, compilateur originel de Linux sous licence GPL, LLVM/Clang, repris par Apple pour ses macs grâce à sa licence Apache, ICC, développé par Intel et MSVC, celui de Microsoft. (réservé à Windows, au passage, là où ses concurrents supportent également Linux)

 

Historiquement, ICC a été une valeur sûre, mais il fallait passer à la caisse pour pouvoir l’utiliser, et le bousin était connu pour désavantager affreusement AMD au passage ; force est de constater que les choses ont changé. Désormais, les compilateurs libres que sont GCC et LLVM ont atteint un niveau excellent, en dépit de toute la complexité des dernières moutures des langages de programmation, C++20 en tête. Il est même devenu possible d’utiliser Clang sur la dernière version de Visual Studio ; et ICC possède désormais une branche basée sur LLVM, qui surpasse la précédente en matière d’optimisations poussées. Son seul désavantage, partagé également avec LLVM, et de dérouler à outrance les boucles, ce qui tire inutilement sur le cache des micro-opérations… mais permet également d’appliquer des transformations de manière plus aisée.

 

Si le libre n’arrive pas à s’imposer dans tous les domaines de l’informatique, voilà un domaine dans lequel il est désormais difficile de s’en passer, pour notre plus grand bonheur en ce qui concerne les fuites. Pourvu que cela dure ! (Source : Agner Fog)

 

llvm logo

 Il fallait bien une illustration, et LLVM est fortement photogénique dans le genre !

Un poil avant ?

Il y a bien un SSD 990 PRO en chemin chez Samsung

Un peu plus tard ...

L'énorme 55" Odyssey Ark de Samsung se précise !

Les 13 ragots
Les ragots sont actuellement
ouverts à tous, c'est open bar !
par Un ragoteur sans avis du Grand Est, le Jeudi 18 Août 2022 à 20h42  
Par contre la définition qu'il donne de ces objets éligible à cette optimisation pourrait être mise à jour: le standard c++ les restreint aux objets "trivially copyable", qui doivent respecter certaines règles (pas de définitions utilisateur des constructeurs move/recopie, ni des opérateurs d'assignement move/recopie, ni du destructeur, etc...) (il parle bien des recopie mais pas des moves, probable que ces chapitres n'ont pas été mis à jour depuis c++11).
par Un ragoteur sans avis du Grand Est, le Jeudi 18 Août 2022 à 20h32  
Super intéressant ses bouquins. Ça fourmille de détailles passionnants
Mais je reste un peu sur ma faim sur un sujet, pas un mot sur les Copy-Elision, hormis un tout petit "In simple cases, the compiler may be able to avoid the calls to the copy constructor and the
destructor by constructing the object on its final destination, but do not count on it".
Pourtant, ça aurait presque mériter un chapitre entier, chaque compilateur gérant ça un peu comme il le veut (et pour cause, le standard c++ leur en laisse une grande latitude).
De ce que j'ai vu, gcc serait légèrement en retrait derrière Clang sur les cas couverts. Et MSVC serait loin derrière, paraît-il (mais pas testé ).
Dans tous les cas, ça se produirait beaucoup moins souvent que je ne le croyais initialement, dans un programme lambda. C'est pour ça qu'un "guide des bonnes pratiques" pour favoriser leur survenue serait le bienvenu (je suis en train d'essayer d'en rédiger un), vu l'impact que ça peut potentiellement avoir sur les perfs, par les nombreuses copies inutiles ainsi éludés dans un programme, juste en modifiant un peu la façon de les écrire, en prenant ça en compte lors du développement.
Les moves c'est bien, mais ça ne règle pas tout

Par contre, j'avais récemment lu quelque part que MSVC était incapable d'utiliser les registres CPU pour le passage et le retour d'arguments par valeur, autour d'une fonction, pour de petits objets simples. Et bien maintenant j'en ai la confirmation et je sais pourquoi
En fait c'était pas exactement ça, c'est plutôt que les systèmes Windows 64-bits limitent la taille de ces objets à 1 registres maximum, et pas plus de 4 arguments au total, là où Linux accepte des objets jusqu'à 16 octets (2 registres), et en bien plus grand nombres.
par Un ragoteur sans avis du Grand Est, le Mardi 16 Août 2022 à 18h57  
par Un ragoteur libre en Île-de-France, le Mardi 16 Août 2022 à 18h18
Ben justement... Avec les sources, vous pouvez compiler un gcc dépourvu de la "protection" (un simple hash) qui verrouille -O2 et + dans les binaires fournis par Microchip.
Ça ça va pour la maison, mais ma boîte fait ça dans les règles, si il faut, elle a les moyen de payer une licence. D'autant qu'ils ont des offres mensuelles vraiment pas chère.
Non, c'est surtout que je n'en ai pas forcément besoin, et que j'ai déjà vu de belles bouses sur de l'O3 par le passé, qui m'ont un peu refroidi. Bon, c'était une très vieille version, probablement fixé aujourd'hui. Mais depuis, je ne suis plus très téméraire, alors tant que je peux rester sur de l'O0, c'est aussi préférable pour le debug.
par Un ragoteur libre en Île-de-France, le Mardi 16 Août 2022 à 18h18  
par Un ragoteur sans avis du Grand Est, le Mardi 16 Août 2022 à 18h16
Bingo, c'est eux. Ils font payer les plus haut niveaux d'optimisations, mais ils fournissent effectivement les sources, j'ai déjà eu l'occasion d'y fureter le museau.
Ben justement... Avec les sources, vous pouvez compiler un gcc dépourvu de la "protection" (un simple hash) qui verrouille -O2 et + dans les binaires fournis par Microchip.
par Un ragoteur sans avis du Grand Est, le Mardi 16 Août 2022 à 18h16  
par Un ragoteur libre pas en Île-de-France, le Mardi 16 Août 2022 à 17h19
Si le fabricant en question est Microchip, alors ils publient en effet les sources de leur gcc modifié. Par exemple, pour les MCU ARM.
Bingo, c'est eux. Ils font payer les plus haut niveaux d'optimisations, mais ils fournissent effectivement les sources, j'ai déjà eu l'occasion d'y fureter le museau.
C'est une vieil boîte maintenant, Clang n'existait pas à l'époque. Sinon, probable qu'ils seraient partis là-dessus.
par Un ragoteur libre pas en Île-de-France, le Mardi 16 Août 2022 à 17h19  
par Nicolas D., le Mardi 16 Août 2022 à 15h24
Ca ne viole pas la GPL, ça ? Si tu fais des modifs, tu es censé les intégrer ou les proposer au projet parent, non ?
Si le fabricant en question est Microchip, alors ils publient en effet les sources de leur gcc modifié. Par exemple, pour les MCU ARM.
par Nicolas D., le Mardi 16 Août 2022 à 15h24  
par Un ragoteur sans avis du Grand Est, le Mardi 16 Août 2022 à 09h53
C'est pas anodin, en dehors de x86, beaucoup de boîtes adaptent les compilo existant pour les µarchi qu'elles mettent au point.
Le compilo que j'utilise au taf, c'est un gcc, mais adapté par le fabricant des MCU.
Ca ne viole pas la GPL, ça ? Si tu fais des modifs, tu es censé les intégrer ou les proposer au projet parent, non ?
par Un ragoteur sans avis du Grand Est, le Mardi 16 Août 2022 à 09h53  
C'est pas anodin, en dehors de x86, beaucoup de boîtes adaptent les compilo existant pour les µarchi qu'elles mettent au point.
Le compilo que j'utilise au taf, c'est un gcc, mais adapté par le fabricant des MCU.
par Une ragoteuse à forte poitrine en Auvergne-Rhône-Alpes, le Mardi 16 Août 2022 à 05h10  
par Je ragondin des Hauts-de-France, le Mardi 16 Août 2022 à 04h16
Pour les Dev, çà ne change strictement rien puisque la licence est sur le compilateur.
Donc à moins de recompiler le compilateur GCC ou LLVM, il n'y a rien à fournir à qui que ce soit
Si je compile du code, c'est la licence que j'aurais choisi d'y appliquer et pas la licence du compilateur.
Sinon tu imagines qu'il y aurait beaucoup de code source dans la balade !!!
Un peu de sérieux, je parle de dev en compilation, c'est pourtant très explicite. C'est à dire ceux qui font le compilateur, et donc il est question de la licence du compilateur qu'ils dev.
par Je ragondin des Hauts-de-France, le Mardi 16 Août 2022 à 04h16  
par Une ragoteuse à forte poitrine en Auvergne-Rhône-Alpes, le Lundi 15 Août 2022 à 20h39
Pour les dev en compilation il y a une différence fondamentale entre GCC et LLVM, c'est la licence.

GCC est sur une licence GPL qui oblige la re-distribution en open-source des modifications du compilateur.
Alors que LLVM a une licence Apache 2.0 qui autorise de ne pas re-distribuer en open-source les modifications.
Pour les Dev, çà ne change strictement rien puisque la licence est sur le compilateur.
Donc à moins de recompiler le compilateur GCC ou LLVM, il n'y a rien à fournir à qui que ce soit
Si je compile du code, c'est la licence que j'aurais choisi d'y appliquer et pas la licence du compilateur.
Sinon tu imagines qu'il y aurait beaucoup de code source dans la balade !!!
par Nicolas D., le Mardi 16 Août 2022 à 02h06  
par Une ragoteuse à forte poitrine en Auvergne-Rhône-Alpes, le Lundi 15 Août 2022 à 20h39
C'est un choix de LLVM pour "mieux protéger" les entreprises, est ce que c'est une bonne chose pour autant?
Chacun se fera son avis.
C'est rétrospectivement grâce à ça qu'il a percé, vu qu'il s'a eu un gros coup de pouce d'Apple
par Une ragoteuse à forte poitrine en Auvergne-Rhône-Alpes, le Lundi 15 Août 2022 à 20h39  
Pour les dev en compilation il y a une différence fondamentale entre GCC et LLVM, c'est la licence.

GCC est sur une licence GPL qui oblige la re-distribution en open-source des modifications du compilateur.
Alors que LLVM a une licence Apache 2.0 qui autorise de ne pas re-distribuer en open-source les modifications.

Pour le grand publique cela ne change pas grand chose (du moins aujourd'hui), mais pour les petites entreprises cela rend plus complexe de profiter du travail des autres (en particulier les entreprises qui font des petits accélérateurs). Car cela oblige à reprogrammer de son coté ce qu'on pu faire des concurrents. Bref on retombe dans un système en partie close-source assez peu efficace.
On est par exemple (dans un cas extrême) pas à l'abri d'avoir dans le futur des versions LLVM pour Apple silicon closed-source.

C'est un choix de LLVM pour "mieux protéger" les entreprises, est ce que c'est une bonne chose pour autant?
Chacun se fera son avis.