LLVM 3.4 et Clang 3.4

Posté par Sylvestre Ledru (site web personnel) le 14 janvier 2014 à 12:01. Édité par rewind, Yves Bourguignon, Benoît Sibaud, claudex, Xavier Teyssier, Nÿco et Florent Zara. Modéré par Florent Zara. Licence CC By‑SA.

Étiquettes :

jan.

2014

A-t-on encore besoin de présenter LLVM et Clang ? Cette suite de compilation est désormais bien établie, en particulier dans le monde du logiciel libre où elle est utilisée dans de nombreux projets (Emscripten, llvmpipe, entre autres). L'application la plus en vue associée à LLVM est sans aucun doute Clang, le compilateur C/C++/ObjectiveC officiel du projet.

Le 6 janvier dernier sont sorties les versions 3.4 de LLVM et de Clang. Les nouveautés sont détaillées dans la suite de la dépêche.

Que ce soit pour LLVM 3.4 ou Clang 3.4, ce sont les dernières versions qui utiliseront C++98. Progressivement, ces deux projets vont utiliser des fonctionnalités de C++11. Cette décision a donné lieu à une très longue discussion sur la liste de diffusion, notamment pour permettre une migration des chaînes de compilation utilisées ça et là pour compiler LLVM. Maintenant, une discussion commence pour savoir quels compilateurs seront ciblés et donc quelles fonctionnalités de C++11 pourront être utilisées. L'ensemble de départ comprend Visual Studio 2012, Clang 3.1 et GCC 4.7.

LLVM 3.4

Passes d'optimisation

La passe de simplification d'appel de bibliothèque (qui permet par exemple de transformer un exit(3) en return 3 quand il est appelé dans main), a été supprimée en tant que telle. Ses fonctionnalités sont maintenant intégrées dans d'autres passes d'optimisation.

La vectorisation des boucles, qui déroule certaines boucles for, est maintenant activée pour -Os et -O2, plutôt que -O3 précédemment.

La vectorisation SLP, qui transforme des groupes d'instructions simples en instructions vectorielles, est également activée par défaut.

Architectures

La gestion de l'architecture R600 présente dans les cartes graphiques AMD n'est plus considérée comme expérimentale. On peut également noter des améliorations générales concernant la prise en charge des architectures GPU. La gestion des espaces d'adressage existe depuis longtemps dans LLVM mais n'était pas vraiment utilisée jusqu'à récemment. Avec l'arrivée du GPGPU, il est devenu nécessaire de bien faire la différence entre les espaces d'adressage (celui de la RAM et celui de la carte graphique) et donc les compilateurs doivent gérer ces espaces d'adressage de la bonne manière. Dans LLVM 3.4, il n'est plus possible de réaliser un bitcast entre des pointeurs de différents espaces d'adressage, il faut désormais utiliser la nouvelle instruction addrspacecast. De plus, les pointeurs de différents espaces d'adressage peuvent désormais être de taille différente.

La gestion de l'architecture PowerPC a vu de nombreuses améliorations dans la qualité du code produit, notamment un meilleur ordonnancement des instructions pour les cœurs embarqués, une meilleure génération des prologues et épilogues, la génération d'instructions particulières ou vectorielles.

La gestion de l'architecture Sparc a permis de grosses améliorations sur de nombreux points importants : la gestion des flottants 128 bits, la gestion des exceptions, la gestion de la mémoire locale à un thread. En plus, l'architecture Sparc V9 (64 bits) est gérée de manière expérimentale, et la compilation JIT est désormais prise en charge.

Autres améliorations

Le binding OCaml de LLVM est maintenant plus complet et couvre l'ensemble des bibliothèques LLVM.

Clang 3.4

Meilleurs diagnostics

Clang est connu depuis le début pour offrir de très bons diagnostics, ce qui a poussé GCC a rattraper son retard. Mais Clang n'en reste pas moins actif pour autant. Et cette version 3.4 est l'occasion d'apporter de nouveaux diagnostics. Parmi tous ceux qui ont été ajoutés, on peut retenir :

-Wheader-guard prévient si les noms utilisés ne correspondent pas :

#ifndef multiple
#define multi
#endif

renverra : warning: ‘multiple’ is used as a header guard here, followed by #define of a different macro [-Wheader-guard]

-Wloop-analysis prévient si la variable de boucle est incrémentée à l'intérieur de la boucle.

void foo(char *a, char *b, unsigned c) {
      for (unsigned i = 0; i < c; ++i) {
            a[i] = b[i];
            ++i;
      }
}

renverra : warning: variable ‘i’ is incremented both in the loop header and in the loop body [-Wloop-analysis]

En plus, des propositions de correction ont été ajoutées dans beaucoup de cas, comme quand -> a été utilisé à la place de . et vice-versa, ou pour des noms de fonctions/méthodes proches avec un nombre de paramètres différent.

Options de compilation

L'optimisation à la liaison n'est plus déclenché avec -O4 mais avec -flto, ce qui permet de l'utiliser pour n'importe quel niveau d'optimisation.

Sylvestre Ledru sera ravi d'apprendre qu'il va supprimer 49 erreurs dans la recompilation de l’archive Debian avec Clang, puisque l'option -O ne provoquera plus d'erreur si le niveau d'optimisation demandé est supérieur à 5. Dans tous ces cas, cela sera considéré comme un -O3. Malheureusement pour lui, le compilateur provoquera des erreurs avec des options non-connues, ce qui risque d'augmenter le nombre d'erreurs, pour les projets qui utilisent des options spécifiques à GCC (mais les différences entre Clang et GCC sont peu nombreuses).

Amélioration de C++

C++1y

La prise en charge de la prochaine version de C++, actuellement baptisée C++1y (puisque C++1x est devenu C++11) et qui sera probablement C++14, se poursuit au rythme des décisions du comité de normalisation. Pour rappel, C++14 sera une mise à jour mineure de C++11, pour corriger les erreurs de C++11, préciser certaines parties de la spécification, et compléter quelques oublis. Il y aura quelques nouveautés, notamment dans la bibliothèque standard mais pas aussi importantes que pour C++11 par rapport à C++03. Les vrais nouveautés (comme <filesystem> ou <networking>) apparaîtront sans doute avec C++17.

`libunwind`

LLVM propose désormais sa propre version de libunwind. Cette bibliothèque est utile pour les systèmes qui ne peuvent pas gérer les exceptions nativement. Ceci complète la série de bibliothèques nécessaires pour l'exécution de programmes C++.

Statut d'OpenMP

OpenMP arrive petit à petit dans Clang. Intel a offert au projet la partie exécution d'OpenMP (l'équivalent de la libgomp pour GCC). L'objectif annoncé est d'être compatible binairement avec GCC et icc, ce qui est une très bonne nouvelle. La gestion complète d'OpenMP (3.1 et 4) devrait arriver dans les prochaines versions de Clang.

Pilote de compilation pour Windows

Clang propose désormais un pilote de compilation pour Windows. Le but est à terme de pouvoir remplacer le pilote de compilation de Visual Studio directement et donc de fournir les mêmes options (des trucs avec des / au lieu de - et des noms cryptiques). Il existe un buildbot qui construit des versions régulièrement même si elles sont encore considérées comme expérimentales.

Aller plus loin

# -O

Posté par Sylvestre Ledru (site web personnel) le 14 janvier 2014 à 12:07. Évalué à 10.

Sylvestre Ledru sera ravi d'apprendre qu'il va supprimer 49 erreurs dans la recompilation de l’archive Debian avec Clang, puisque l'option -O ne provoquera plus d'erreur si le niveau d'optimisation demandé est supérieur à 5.
Ah ah, c'est gentil :) (bon, je suis le responsable de ce changement dans le code Clang donc je triche un peu ;)
- [^] # Re: -O
  
  Posté par Bapt (site web personnel) le 15 janvier 2014 à 23:11. Évalué à 6.
  
  Je trouve que c'est dommage d'accepter des -O9 qui ne veulent rien dire :(, j'aimais bien le fait que ça rejette ça me permettait de faire du ménage dans les ports pourri sous FreeBSD :)
# -Os et les boucles

Posté par claudex le 14 janvier 2014 à 12:12. Évalué à 5.

Je ne comprends pas pourquoi dérouler les boucles optimise la taille (vu qu'il est uitlisé avec -Os). Quelqu'un pour l'expliquer ?

« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
- [^] # Re: -Os et les boucles
  
  Posté par Krunch (site web personnel) le 14 janvier 2014 à 12:34. Évalué à 10. Dernière modification le 14 janvier 2014 à 13:49.
  Je me suis posé la même question mais en fait c'est évident. Pour certaines boucles plus ou moins triviales, les dérouler réduit la taille du code généré puisqu'il n'y a plus besoin de maintenir le compteur de boucle. Par exemple:
```
for (int i = 0; i < 3; i++)
      frob(i);
```
  Dont la traduction naïve pourrait donner :
```
        .cfi_startproc
        pushq   %rbp
        .cfi_def_cfa_offset 16
        movq    %rsp, %rbp
        .cfi_offset 6, -16
        .cfi_def_cfa_register 6
        subq    $16, %rsp
        movl    $0, -4(%rbp)
        jmp     .L2
       .L3:
        movl    -4(%rbp), %eax
        movl    %eax, %edi
        call    frob
        addl    $1, -4(%rbp)
       .L2:
        cmpl    $2, -4(%rbp)
        jle     .L3
        leave
        ret
        .cfi_endproc
```
  Alors qu'en déroulant on pourrait avoir :
```
        .cfi_startproc
        subq    $8, %rsp
        .cfi_def_cfa_offset 16
        xorl    %edi, %edi
        call    frob
        movl    $1, %edi
        call    frob
        popq    %rax
        movl    $2, %edi
        jmp     frob
        .cfi_endproc
```
  Par ailleurs je tiens à nouveau à me plaindre du système de mise en forme de DLFP qui nécessite de passer 5 minutes à éditer son code pour qu'il soit rendu de manière plus ou moins lisible (oui, j'ai déjà ouvert des suivis à ce sujet).
  
  pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
  - [^] # Re: -Os et les boucles
    
    Posté par Benoît Sibaud (site web personnel) le 14 janvier 2014 à 13:51. Évalué à 5.
    
    Par ailleurs je tiens à nouveau à me plaindre du système de mise en forme de DLFP qui nécessite de passer 5 minutes à éditer son code pour qu'il soit rendu de manière plus ou moins lisible (oui, j'ai déjà ouvert des suivis à ce sujet).
    
    À première vue (et après avoir modifié le commentaire précédent), je dirais que tu l'utilises mal : il faut fermer les zones de code, et on peut les typer pour la coloration syntaxique (ici j'ai utilisé C++, asm, asm).
  - [^] # Re: -Os et les boucles
    
    Posté par Blackknight (site web personnel, Mastodon) le 14 janvier 2014 à 18:24. Évalué à -5.
    
    De toutes façons, on s'en fout des perfs, non ? :)
- [^] # Re: -Os et les boucles
  
  Posté par xcomcmdr le 14 janvier 2014 à 12:44. Évalué à 7.
  
  Dérouler les boucles, c'est vieux comme l'informatique.
  
  "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
# Fôtes

Posté par Zarmakuizz (site web personnel) le 14 janvier 2014 à 12:26. Évalué à 2.

La passe de simplification d'appel de bibliothèque (…), a été supprimé en tant que tel.

supprimé e

Ses fonctionnalités sont maintenant intégrés

intégré e s

Faudrait ouvrir une entrée dans le suivi, devoir mettre des espaces autour des caractères de style c'est pas beau.

Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
- [^] # Re: Fôtes
  
  Posté par claudex le 14 janvier 2014 à 12:28. Évalué à 3. Dernière modification le 14 janvier 2014 à 12:29.
  
  Corrigé, merci.
  
  Faudrait ouvrir une entrée dans le suivi, devoir mettre des espaces autour des caractères de style c'est pas beau.
  
  It's not a bug, it's a feature (mais je ne retrouve pas l'entrée de suivi qui en parle).
  
  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
  - [^] # Re: Fôtes
    
    Posté par ariasuni le 14 janvier 2014 à 13:21. Évalué à 2.
    
    Faudrait utiliser autre chose que Markdown pour corriger le problème (Kramdown par exemple). Mais c'est compliqué…
    
    Écrit en Bépo selon l’orthographe de 1990
- [^] # Autre fôtes
  
  Posté par djano le 14 janvier 2014 à 21:43. Évalué à 2.
  
  Les vrais nouveautés (comme ou ) apparaîtront dans doute avec C++17.
  
  => …sans doute…
  - [^] # Re: Autre fôtes
    
    Posté par rewind (Mastodon) le 14 janvier 2014 à 21:56. Évalué à 1.
    
    à l'origine, c'était filesystem et networking mis entre chevrons, comme pour les autres en-têtes C++, mais je crois qu'il a pris ça pour des balises… :/
    - [^] # Re: Autre fôtes
      
      Posté par djano le 14 janvier 2014 à 22:17. Évalué à 2.
      
      Je pense que tu reponds au mauvais commentaire?
      
      Je signalais un faute d'orthographe.
      - [^] # Re: Autre fôtes
        
        Posté par rewind (Mastodon) le 14 janvier 2014 à 23:40. Évalué à 2.
        
        Ha mais oui, mais non ! En fait, je pensais que tu signalais que les en-têtes n'apparaissaient pas mais en fait, ils apparaissent dans la news mais pas dans ton message. Bon, du coup, je crois que je vais sortir.
  - [^] # Re: Autre fôtes
    
    Posté par claudex le 15 janvier 2014 à 14:18. Évalué à 3.
    
    Corrigé, merci.
    
    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# mélange de langage ?

Posté par Nicolas Boulay (site web personnel) le 14 janvier 2014 à 16:30. Évalué à 2.

Est-ce que llvm propose un moyen de mélanger des langages et de faciliter l'usage de code déjà existant codé dans autre chose ?

En général, les conventions d'appels suivi sont celles du C, donc on oublie tout ce qui ressemble à de l'objet, ou un langage avec GC. Cela devient de plus en plus limitant.

"La première sécurité est la liberté"
- [^] # Re: mélange de langage ?
  
  Posté par rewind (Mastodon) le 14 janvier 2014 à 18:23. Évalué à 5.
  
  Est-ce que llvm propose un moyen de mélanger des langages et de faciliter l'usage de code déjà existant codé dans autre chose ?
  
  Pas plus que le C ou la JVM (chacun dans leur style). C'est-à-dire qu'on pourrait imaginer tout un tas de langages qui compilent vers le langage LLVM qui sert de représentation intermédiaire dans le compilateur. Mais comme tu le dis, on aura sans doute des conventions de nommage à gérer et des conventions d'appels (même si LLVM sait gérer les conventions d'appel).
  
  Je pense que si tu voulais ce genre de chose, il faudrait spécifier un peu plus que le langage, il faudrait aller plus loin. Faire un peu ce que MS a essayé de faire avec dotNet.
- [^] # Re: mélange de langage ?
  
  Posté par lasher le 14 janvier 2014 à 18:36. Évalué à 4.
  
  Oui enfin, l'ABI entre icpc (C++) et g++ est différente même sous Linux. Tu fais comment dans ce cas ? C et Fortran ont une ABI compatible (il suffit de mettre les underscores au bon moment, au bon endroit pour les noms de symboles). Quel genre d'interaction voudrais-tu voir ?
  
  Théoriquement, Si tu utilises les bons front-ends (clang pour C, clang++ pour C++, le front-end de OCaml, etc.), ils devraient générer le pseudo-assembleur de LLVM, et donc tu devrais pouvoir tout faire interagir. Je ne sais pas si c'est vrai, et quelles sont les limitations qui l'empêchent si c'est faux.
  - [^] # Re: mélange de langage ?
    
    Posté par djano le 14 janvier 2014 à 21:44. Évalué à 3.
    
    L'ABI C++ n'est pas standardisee et notamment le name mangling.
    L'ABI generee par g++ a egalement changee au cours du temps et des versions.
    - [^] # Re: mélange de langage ?
      
      Posté par lasher le 14 janvier 2014 à 22:23. Évalué à 2.
      
      L'ABI C++ n'est pas standardisee et notamment le name mangling.
      Oui, c'est ce que je voulais dire, mais j'ai oublié de le mentionner. Merci ! :)
    - [^] # Re: mélange de langage ?
      
      Posté par Gof (site web personnel) le 15 janvier 2014 à 08:33. Évalué à 5.
      
      Si, l'ABI C++ est standardisée depuis 2001 (autant que celle du C).
      GCC n'a plus changé d'ABI depuis qu'ils utilisent ce standard.
      - [^] # Re: mélange de langage ?
        
        Posté par Sylvestre Ledru (site web personnel) le 15 janvier 2014 à 09:10. Évalué à 4.
        
        D'autant que LLVM fournit la mécanique pour le demangling:
        http://llvm.org/docs/doxygen/html/classllvm_1_1Mangler.html
        (même si c'est un peu sport)
      - [^] # Re: mélange de langage ?
        
        Posté par cedric le 15 janvier 2014 à 10:51. Évalué à 6.
        
        GCC n'a plus changé d'ABI depuis qu'ils utilisent ce standard.
        
        Si je me souviens bien aux alentours de 2007, ils ont casse par inadvertance l'ABI. Mais je crois que c'etait uniquement un truc dans la STL. Mais sinon l'ABI du C++11 de GCC n'est pas encore considere comme stable et toutes les applications qui l'utilisent seront a recompiler avec le prochain GCC. C'est un exercice tres difficile de maintenir l'ABI d'une lib C++ stable plus de quelques annees. Pour le coup, le projet Qt est tres impressionnant pour avoir reussi a tenir 7 ans entre deux cassages d'ABI, si je ne me trompe pas.
        
        [^] # Re: mélange de langage ?
        
        Posté par Benoît Sibaud (site web personnel) le 15 janvier 2014 à 11:25. Évalué à 7.
        
        cf http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html
        
        GCC 3.1.0: libstdc++.so.4.0.0 (Incompatible with previous) // May 15, 2002
        
        …
        
        GCC 3.2.0: libstdc++.so.5.0.0 (Incompatible with previous) // August 14, 2002
        
        …
        
        GCC 3.4.0: libstdc++.so.6.0.0 (Incompatible with previous) // April 20, 2004
        
        …
        
        GCC 4.2.1: libstdc++.so.6.0.9 (Note 3: This release (but not previous or subsequent) has one known incompatibility, see 33678 in the GCC bug database. // July 18, 2007
        
        …
        
        [^] # Re: mélange de langage ?
        
        Posté par djano le 15 janvier 2014 à 15:15. Évalué à 3.
        
        Merci! ;)
        
        [^] # Re: mélange de langage ?
        
        Posté par Gof (site web personnel) le 15 janvier 2014 à 22:33. Évalué à 4.
        
        Là, on parle de la librairie standard. Pas de l'ABI du langage lui même qui est important pour les bindings.
        La librairie C aussi en est à sa version 6 (glibc.so.6).
  - [^] # Re: mélange de langage ?
    
    Posté par Sytoka Modon (site web personnel) le 15 janvier 2014 à 09:43. Évalué à 10.
    
    C et Fortran ont une ABI compatible (il suffit de mettre les underscores au bon moment, au bon endroit
    
    C'est complètement faux !
    
    Tu parles du Fortran 77, une très ancienne version qui a plus de 35 ans… Depuis le Fortran 90, le Fortran moderne, il y a la notion de Module donc d'espace de nom et chaque compilateur gère le mangling comme il veut. Cela va même plus loin car l'ordre des champs dans un type est laissé au choix du compilateur par défaut (ce qui n'est pas le cas en C) pour des questions de performances et d'alignement…
    
    Fortran est aujourd'hui un langage objet (héritage simple). C'est un langage qui a énormément évoluer (c'est pour cela qu'il n'est pas encore mort), bien plus que le C.
    - [^] # Re: mélange de langage ?
      
      Posté par nazcafan le 15 janvier 2014 à 14:54. Évalué à 0.
      
      Ce commentaire est un appeau à troll. Du coup, je m'y colle : tu ne crois pas que Fortran n'est pas mort à cause des tonnes d'ancien code qu'on doit se traîner encore aujourd'hui, plutôt ?
      
      Parce que Fortran a beau évoluer, le support de gcc pour les évolutions post Fortran 90 est au mieux parcellaire, le support llvm inexistant (oui, je sais, il y a un projet Flang et tout ça). Les mauvaises langues diraient que les 3 personnes qui siègent dans le comité de normalisation ont perdu tout contact avec la communauté des programmeurs Fortran.
      Alors bon, les évolutions de Fortran, à part l'intérop avec le C (et encore) je pense pas que ça fasse rêver beaucoup de monde, autant utiliser un langage moderne directement.
      - [^] # Re: mélange de langage ?
        
        Posté par Troy McClure (site web personnel) le 15 janvier 2014 à 15:53. Évalué à 3.
        
        N'oubliez pas de signer la pétition ! http://www.fortranstatement.com/cgi-bin/petition.pl
      - [^] # Re: mélange de langage ?
        
        Posté par Albert_ le 15 janvier 2014 à 22:38. Évalué à 7.
        
        Peut etre que le C n'est pas fait pour faire du calcul contrairement a fortran et qu'il est beaucoup plus facile, efficace et moins buggue de developper des modeles numerique dans un langage fait pour?
        
        [^] # Re: mélange de langage ?
        
        Posté par Zylabon le 15 janvier 2014 à 22:43. Évalué à 3. Dernière modification le 15 janvier 2014 à 22:43.
        
        À ton avis entre une voiture de sport des années 1900 et une twingo des années 2000, qu'est-ce qui va le plus vite ?
        
        Please do not feed the trolls
        
        [^] # Re: mélange de langage ?
        
        Posté par lolop (site web personnel) le 16 janvier 2014 à 08:52. Évalué à 9.
        
        Une voiture de sport des années 2010 - crois tu que les sociétés qui vendent des compilateurs Fortran pour leurs machines (typiquement Intel) délaissent l'optimisation du code machine?
        
        Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
        
        [^] # Re: mélange de langage ?
        
        Posté par Albert_ le 16 janvier 2014 à 09:58. Évalué à 6.
        
        et donc niveau calcul numérique tu considères le C comme étant un langage fait pour ?
        
        C'est une opnion … pas forcément partagé par tout les numericiens.
      - [^] # Re: mélange de langage ?
        
        Posté par Sytoka Modon (site web personnel) le 16 janvier 2014 à 13:55. Évalué à 9.
        
        En calcul numérique, cela peut être bien plus simple de faire du Fortran. En C, tu te fais chier avec les valeurs, les pointeurs et les références… En Fortran, tout passe par adresse. Il y a tout plein de code matlab que tu fais facilement en Fortran par exemple. De très nombreux thésards n'ont aucun notion de programmation en démarrant…
        
        Évidement, il n'y a aucun intérêt à faire du Fortran pour un clickodrome ou un serveur web. A chacun son domaine. Moi j'aime bien aussi la philosophie Erlang ou tout est immutable et passe par copie ;-)
        
        Le support du Fortran par GCC est très loin d'être nul, c'est pas parce que c'est pas dans LVVM que GCC ne fait rien ! Le support des Co-Array est en cours (Fortran 2008 de tête), les Co-Array sont des tableaux qui fonctionne de manière transparent sur un cluster. C'est faisable avec MPI et/ou OpenMP (sur un noeud) mais ici, l'API est simplifié. La bascule vers des codes parallèle est importante et ne doit pas être que l'affaire des spécialiste. Fortran cherche sa voie très calcul numérique. A chacun ses choix.
    - [^] # Re: mélange de langage ?
      
      Posté par lasher le 15 janvier 2014 à 16:56. Évalué à 3.
      
      C'est complètement faux !
      
      … Puis tu fais suivre avec des exemples en F77. Fortran 90 rajoute tout un tas de trucs très utiles (notamment « free form », etc.), mais n'est pas encore objet et … TADAAAAA ! est toujours compatible avec C (en tout cas ifort+gcc, ifort+icc, etc.).
      
      Pour F95 et ses successeurs, je te fais confiance. Ensuite, même si la forme n'y est pas, nazcafan a raison sur un point : j'ai bossé avec des boites allemandes et françaises pour aider à l'optimisation de leurs codes, et tous étaient écrits en F77 ou F90. Je suis certain qu'il existe des codes conséquents écrits en F95 et plus, mais je n'en ai jamais rencontré.
      - [^] # Re: mélange de langage ?
        
        Posté par Albert_ le 15 janvier 2014 à 22:42. Évalué à 6.
        
        F95 c'est quasiment F90 avec juste un ou deux trucs en plus et un peu de nettoyage. Par contre F2001/2003 a introduit la notion d'objet.
      - [^] # Re: mélange de langage ?
        
        Posté par Sytoka Modon (site web personnel) le 16 janvier 2014 à 14:07. Évalué à 4.
        
        F90 rajoute les modules donc c'est à partir de là que tu as du mangling. Si tu ne fais pas de module, tu fait du F77 caché dans l'appellation F90 mais c'est pas du Fortran moderne… C'est avec cette notion de Module que sont généré automatiquement les .mod, équivalents des .h du C qui permettent une vérification forte du typage dès la compilation.
        
        Avec F2003, il y a l'héritage simple mais on sais tous que c'est facile a émuler puisque qu'en gros, un cast suffit (c'est ce que fait GTK). C'est pour cela que je considère (come d'autre) que la bascule importante a eu lieu avec F90.
      - [^] # Re: mélange de langage ?
        
        Posté par magnolia le 26 janvier 2014 à 13:02. Évalué à 7. Dernière modification le 26 janvier 2014 à 13:06.
        
        Les codes numériques sont aujourd'hui majoritairement écrits en MATLAB/Python/C++/C/Fortran. En langage compilés il reste donc C++/C/Fortran.
        
        Une grande partie de la MKL (Math Kernel Library, développée par Intel) est écrite en C, pour que tout soit optimisé aux petits oignons. Une telle optimisation nécessite une très bonne connaissance du compilateur et du processeur pour lequel vous optimisez. Intel sait le faire, mais il ne doit pas y avoir grand monde qui sait le faire correctement.
        
        De nombreux code sont aujourd'hui écrits en C++ et certains codes sont très bien programmés. Cependant, l'écriture de codes numériques nécessitent une bonne connaissance en physique, mathématique, informatique. Les journées ayant un nombre limitées d'heures, il est bon de ne pas se surcharger en "connaissances" informatique. En analyse numérique, il est essentiel de bien maitriser :
        - La gestion de la mémoire
        - L'OpenMP, le MPI
        - Des Design Pattern qui ne ruinent pas la performance
        C'est déjà beaucoup pour une personne qui doit connaître aussi de la physique et des maths (surtout cela d'ailleurs). Se lancer dans l'apprentissage et la maitrise du C++ est une longue route, et l'optimisation du C++ est parfois "surprenante". Par exemple, si vous écrivez :
        
        for (i = 0; i < size; i++) { v[i] = pow((double) (i+1), -2); }
        
        vous verrez que le "vectorizer" va se comporter de manière très différente selon : le type de vecteur utilisé ("vecteur" C, ou std::vector), le compilateur utilisé (gcc ou icc) ainsi que sa version. Il y a 2 ans, icc n'était pas fichu de vectoriser le code lorsque v était un std::vector. J'en avais discuté avec des développeurs Intel qui confirmait ce problème (Voir ici std::vector et vectorisation). Depuis, ce problème a été résolu sur icc, mais une recherche rapide montre que les compilateurs microsoft ont encore du mal avec cela : Problème de vectorisation en C++. J'imagine qu'il y a encore de nombreux problèmes, même avec icc et gcc.
        
        Du fait de l'inexistence de pointeurs (ou plutôt du fait qu'ils ne peuvent pas pointer vers n'importe quoi), le Fortran est bien plus facile à optimiser pour les compilateurs et ce genre de surprise n'existe pas vraiment. C'est un langage facile à utiliser, efficace et propre. Il y a même de très bon bouquins sur les Designs Pattern avec des exemples en Fortran : Design Pattern.
        
        Malheureusement, de nombreux code Fortran sont vraiment programmés avec les pieds d'un point de vue d'un informaticien. Ce n'est pas propre au language, mais aux capacités informatiques des programmeurs qui sont le plus souvent tout d'abord des matheux et des physiciens. Si vous leur donnez entre les mains du C++, vous courez à la catastrophe.
        
        J'ai écrit un code de 30 000 lignes il y a 2 ans en Fortran 2003 (orienté objet) + OpenMP + MPI + MKL. Si c'était à refaire, je choisirai à nouveau ce langage. Alors laissez nous le Fortran. Merci.
        
        [^] # Re: mélange de langage ?
        
        Posté par navaati le 26 janvier 2014 à 13:26. Évalué à 3.
        
        Message intéressant !
        
        Mais je crois que les gens ne pensaient pas à remplacer le Fortran par quelque chose de moins adapté (le C, quelle idée, c'est pour la programmation système et l'interfaçage, le C++ quand à lui ne donne pas assez de garanties statiques au compilateur pour être correctement optimisé, c'est le problème que tu pointes) mais par des langages plus haut niveau et plus adaptés au calcul (et au cerveau des matheux/physiciens).
        
        Par exemple Haskell a de très bonnes bibliothèques de calcul matriciel (repa) et le compilateur a des capacités d'optimisations affolantes tout en gardant une approche très mathématique dans le langage (pas besoin d'apprendre le paradigme impératif pour les scientifiques, qui maîtrisent plus naturellement le paradigme immutable fonctionnel : c'est celui des maths). Ça n'est pas magiques, il y a aussi des choses informatiques à apprendre (lazyness et strictness, importantes en Haskell pour permettre les optimisations), mais c'est déjà un progrès.
        
        La façon de python de donner accès dans un langage simple à des primitives optimisées en C avec numpy est sans doute pas mal aussi.
        
        [^] # Re: mélange de langage ?
        
        Posté par magnolia le 26 janvier 2014 à 13:50. Évalué à 1.
        
        Je n'ai jamais bien réfléchi aux avantages des langages fonctionnels pour l'analyse numérique. Je ne connais pas Haskell mais je connais un peu OCaml et j'avoue ne jamais avoir réfléchi à ce qu'ils peuvent apporter en analyse numérique.
        Mathematica (qui est très fonctionnel) et le F# (Un Objective Caml adapté à .NET) sont utilisés, notamment en Finance. Je crois aussi avoir qu'une université américaine réputée à choisit de faire passer le fonctionnel avant l'orienté objet dans son cursus. Il est donc probable que le fonctionnel soit de plus en plus utilisé par les jeunes générations.
        
        Le Python est assez agréable comme langage de haut niveau, mais on reste dans les langages dans lesquels la "boucle" est "interdite" pour des raisons de performance (Comme Matlab (vieilles versions)/Mathematica/…). Je n'ai jamais pu m'y faire et il y a encore de nombreux algos qui ne s'expriment pas simplement sans boucle. Leur version "vectorielle" est souvent inefficace (par exemple, calculer les distances mutuelles entre n points du plan).
        Julia, développé par des personnes du MIT, semble mélanger les avantages d'un langage dynamique avec un JIT, comme les dernières versions de Matlab. Du coup, on peut faire des boucles sans perdre trop de performance. C'est encore très jeune, mais cela à l'air intéressant : Julia. D'autres personnes pensent mettre un JIT dans Python. Bref, cela bouge pas mal.
        
        Du coup, je préfère rester avec ma "vieille casserole" qui marche très bien : Fortran 2003.
        
        [^] # Re: mélange de langage ?
        
        Posté par lasher le 06 février 2014 à 20:13. Évalué à 4.
        
        Concernant la MKL: entre 10 et 20% est écrite en ASM. Le reste est du C « de base » (car le compilateur peut correctement générer du code de bonne qualité), compilé en plusieurs versions (avec/sans OpenMP, ILP32 ou ILP64, etc.).
        
        Cependant, l'écriture de codes numériques nécessitent une bonne connaissance en physique, mathématique, informatique
        
        Pas d'accord. Enfin pas tout à fait. J'ai besoin d'avoir accès à un physicien/mathématicien lorsqu'il s'agit d'optimiser un code et de vérifier que je ne mets pas en danger la stabilité numérique ou la convergence d'un algo (dans le cas d'une méthode itérative). Mais s'il est toujours utile de connaître un minimum le domaine d'application d'un programme (e.g. éléments finis, etc.), dans 90% des cas, ce que je dois savoir en tant qu'infoteux bas-niveau, c'est comment sont représentés les flottants « normalisés » (IEEE 754) en 32, 64, et 80 bits et « dénormalisés » (spécifiques à l'archi, et souvent lents). Le reste, c'est purement un problème de compilation/optimisation largement à ma portée.
        
        Tu as raison de dire que le temps est limité pour un ingé/scientifique, et qu'il faut donc faire des choix. Mais le problème est que les physiciens/matheux/bla ont eu à « devenir » programmeurs d'un côté pour pouvoir coder leurs modèles (ce qui est très bien), mais aussi à se préoccuper de la machine en dessous (ce qu'ils ne devraient JAMAIS avoir à faire dans l'idéal).
        
        Il existe tout un tas d'efforts en ce moment pour correctement procéder à la séparation de rôles (« separation of concerns », je ne sais pas bien comment le traduire) : d'un côté le physicien/mathématicien qui code son modèle (le langage importe peu), et de l'autre le « tuning expert » qui connaît la machine cible et sait comment correctement causer au compilateur et à la machine en règle générale. Par exemple, il existe les Concurrent Collections (CnC), création dans un labo d'Intel à la base pour le langage C++, mais dont la spécification a donné lieu à des implémentations en Python, Java, etc. Le principe est simple : on écrit son code par « étapes » (steps). Chaque étape doit être une fonction_pure (i.e. le résultat doit être le même à chaque fois que la fonction doit traiter des données identiques, et qui n'a pas d'effet de bord). Le programmeur d'application doit ensuite écrire comment les différentes étapes sont coordonnées, en exprimant explicitement les relations de dépendance de contrôle et de données entre étapes.
        
        J'ai écrit un code de 30 000 lignes il y a 2 ans en Fortran 2003 (orienté objet) + OpenMP + MPI + MKL. Si c'était à refaire, je choisirai à nouveau ce langage. Alors laissez nous le Fortran. Merci.
        
        Là-dessus je te rejoins parfaitement. Le meilleur langage pour programmer quelque chose, c'est celui où tu te sens à l'aise. N'ayant eu que des codes F77 ou F90 "non objet" me passer sous les yeux, je t'avoue que j'ai versé quelques larmes de sang, mais c'était loin d'être aussi terrible que ce qu'on m'avait décrit (bon, les boucles avec étiquettes numériques en F77, ou les blocs COMMON, je m'en serais bien passé).
  - [^] # Re: mélange de langage ?
    
    Posté par Nicolas Boulay (site web personnel) le 16 janvier 2014 à 09:48. Évalué à 1.
    
    Je pensais au cas particuliers d'une gestion des EFL (écrites en C) avec ocaml qui a un GC. Le mélange des 2 n'a pas l'air simple du tout.
    
    "La première sécurité est la liberté"
# Binding OCaml

Posté par programLyrique le 14 janvier 2014 à 18:40. Évalué à 3.

Le binding OCaml de LLVM est maintenant plus complet et couvre l'ensemble des bibliothèques LLVM.

J'espère que les erreurs de segmentation intempestives qui avaient lieu lorsqu'on compilait un code invalide ont été supprimées, pour laisser place à quelque chose de plus informatif…
# Simplification d'appel de la lib ?

Posté par Zylabon le 14 janvier 2014 à 19:19. Évalué à 1.
La passe de simplification d'appel de bibliothèque (qui permet par exemple de transformer un exit(3) en return 3 quand il est appelé dans main)

Je me demandais si ça respectait la sémantique du langage, considérez le programme "real world" suivant :
```
#include <stdlib.h>
int main(int ac, char ** av){
  if(ac){
    main(0,av);
    return 2;
  }else
    exit(0);
}
```
Il est cassé par cette optimisation.

Please do not feed the trolls
- [^] # Re: Simplification d'appel de la lib ?
  
  Posté par rewind (Mastodon) le 14 janvier 2014 à 20:16. Évalué à 7.
  
  Je pense que ça devait être un peu plus subtil que remplacer en bourrin tous les appels à exit en return…
- [^] # Re: Simplification d'appel de la lib ?
  
  Posté par ariasuni le 15 janvier 2014 à 09:09. Évalué à 1.
  
  Je ne comprends pas, quelle sémantique?
  
  Écrit en Bépo selon l’orthographe de 1990
  - [^] # Re: Simplification d'appel de la lib ?
    
    Posté par LupusMic (site web personnel, Mastodon) le 15 janvier 2014 à 11:27. Évalué à 1.
    
    Si exit(0) est remplacé par un bête return, le programme ne s'arrêtera pas immédiatement si ac est non nul (remarque que ac ne peut pas être non-nul quand invoqué par le bootstrap du créé par le compilateur).
    - [^] # Re: Simplification d'appel de la lib ?
      
      Posté par ariasuni le 15 janvier 2014 à 12:05. Évalué à 2.
      
      Ah oui j’avais loupé le plus important…
      
      Écrit en Bépo selon l’orthographe de 1990
- [^] # Re: Simplification d'appel de la lib ?
  
  Posté par Gof (site web personnel) le 22 janvier 2014 à 10:40. Évalué à 8.
  C++ 11 §3.6.1 [basic.main.start]
  1. The function main shall not be used within a program. The linkage of main is implementation-defined. […]
  En C++, ton code est invalide. et cette optimisation est valide. Peut être que LLVM ne fait cette optimisation que pour du code en C++?
  Je n'ai pas pu trouvé dans le code de LLVM l'endroit ou cette optimisation est faite pour vérifier.
  - [^] # Re: Simplification d'appel de la lib ?
    
    Posté par Zylabon le 22 janvier 2014 à 19:45. Évalué à 2.
    
    Je doute que l'optimisation soit faite, il ne permet d'économiser qu'un seul return par processus.
    
    Please do not feed the trolls
# Rebuild Debian

Posté par nonas le 16 janvier 2014 à 14:17. Évalué à 5.
- Est-ce qu'il est prévu de reconstruire l'ensemble des paquets de Debian avec cette version ? (comme réalisé avec les versions précédentes : http://clang.debian.net/)
- À titre d'information, ça prend combien de temps (et sur quelle type de machine), combien de RAM et d'espace disque de faire ça ?
- À part la création du chroot, où peut-on trouver les scripts permettant d'automatiser les builds et la génération des rapports ?
- Est-ce que des travaux ont été réalisés depuis l'été dernier sur l'aspect 'Build time, binary size or performances' ?
- Est-il pertinent d'ouvrir systématiquement un bug chez Debian pour les paquets qui ne build pas comme tu -Sylvestre- l'as déjà fait pour certains : clang-ftbfs ?
En tout cas, beau travail !
- [^] # Re: Rebuild Debian
  
  Posté par Sylvestre Ledru (site web personnel) le 16 janvier 2014 à 15:09. Évalué à 9.
  
  Est-ce qu'il est prévu de reconstruire l'ensemble des paquets de Debian avec cette version ? (comme réalisé avec les versions précédentes : http://clang.debian.net/)
  
  Oui, je l'ai fait pour la 3.4rc1 pour tester clang (j'ai pas publié les résultats mais ils sont globalement bons).
  Je viens justement de traiter les résultats avec la 3.4 mais il y a des problèmes liés à l'infra de rebuild (trop de processus qui freezent). J'espère publier les résultats la semaine prochaine.
  
  À titre d'information, ça prend combien de temps (et sur quelle type de machine), combien de RAM et d'espace disque de faire ça ?
  
  On utilise AWS pour faire le rebuild. Généralement, ça met 7 à 8 heures pour tout rebuild avec environ 50 noeuds.
  La plupart des packages sont rapidement recompilés, c'est les gros packages qui font que ça traine (libreoffice, gcc, etc).
  
  On utilise généralement soit les noeuds m1.medium, soit m2.xlarge:
  http://aws.amazon.com/ec2/instance-types/
  
  À part la création du chroot, où peut-on trouver les scripts permettant d'automatiser les builds et la génération des rapports ?
  
  Le code pour gérer et lancer les builds est accessible ici:
  http://anonscm.debian.org/gitweb/?p=collab-qa/cloud-scripts.git;a=summary
  
  Le code qui va parser les logs, trouver les erreurs et faire des listes est accessible ici:
  http://anonscm.debian.org/viewvc/collab-qa/collab-qa-tools/
  
  Est-ce que des travaux ont été réalisés depuis l'été dernier sur l'aspect 'Build time, binary size or performances' ?
  
  Non, par contre, on (Léo Cavaillé, Paul Tagliamonte et moi même) a beaucoup travaillé sur un projet intitulé Debile pour que tout ça soit transparent avec plein d'autres choses (dont des dépôts de package construits avec).
  Ca devrait simplifier tout ça… Help is welcome!
  
  D'ailleurs, j'ai quelques idées de projet pour le GSoC 2014: https://wiki.debian.org/SummerOfCode2014/Projects
  
  Est-il pertinent d'ouvrir systématiquement un bug chez Debian pour les paquets qui ne build pas comme tu -Sylvestre- l'as déjà fait pour certains : clang-ftbfs ?
  
  Oui, je le pense. J'ai jamais eu de retour négatif quant à cette initiative.
  
  Je pousse pour que ça devienne un release goal: https://wiki.debian.org/ReleaseGoals/clang-secondary-compiler
  - [^] # Re: Rebuild Debian
    
    Posté par Sytoka Modon (site web personnel) le 16 janvier 2014 à 21:15. Évalué à 2.
    
    s/c'est les gros packages/ce sont les gros paquets/
  - [^] # Re: Rebuild Debian
    
    Posté par nonas le 16 janvier 2014 à 22:51. Évalué à 1.
    
    Merci pour ces réponses.
    Je vais essayer de monter un sbuild avec clang sur ma machine (déjà pour voir si j'y arrive) et éventuellement ouvrir des bugs. J'ai vu, d'après tes bugs et patchs, que certaines corrections étaient triviales.
    Je me suis aussi inscrit aux mailings lists de debile. Si il y a des choses spécifiques que je puisse tester, n'hésite pas (par contre j'ai presque tout à apprendre) ;-)
    - [^] # Re: Rebuild Debian
      
      Posté par Sylvestre Ledru (site web personnel) le 17 janvier 2014 à 09:01. Évalué à 4.
      
      Le sbuild modifié est pas toujours nécessaire.
      Assez souvent, CC=clang CXX=clang++ dpkg-buildpackage suffit à reproduire le problème (si upstream accepte la surcharge de CC/CXX).
      
      Pour Debile, c'est surtout sur IRC que ça se passe (#debile sur OFTC). Et, enfin, Léo et moi en faisons une présentation samedi prochain à la Mini Debconf:
      https://france.debian.net/evenements/minidebconf2014/
  - [^] # Re: Rebuild Debian
    
    Posté par Krunch (site web personnel) le 18 janvier 2014 à 05:54. Évalué à 4.
    
    On utilise AWS pour faire le rebuild.
    
    Ça inclut les builds « officiels » ? Si c'est le cas, Amazon pourrait techniquement backdoorer toutes les installations Debian « standards ». S'il y a eu une discussion publique à ce sujet, je veux bien le lien.
    
    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
    - [^] # Re: Rebuild Debian
      
      Posté par Sylvestre Ledru (site web personnel) le 18 janvier 2014 à 13:39. Évalué à 4.
      
      Non, c'est juste pour les expériences (vérification si les packages construisent toujours, test de nouvelles versions de openjdk, clang, etc). La plupart du temps, on conserve même pas les packages.
      
      Pour les packages officiels, on a nos propres services de build.
      
      Après, il y a des discussions pour utiliser AWS comme CDN sur les listes de diffusion (ca doit etre debian-devel ou sur debian-project).
    - [^] # Re: Rebuild Debian
      
      Posté par oao le 21 janvier 2014 à 14:15. Évalué à 3.
      
      Très risqué pour d'Amazon. On peut builder le même programme avec le même compilateur et les mêmes options sur le même OS et on devrait obtenir (si je ne m'abuse) le même résultat. Si ce n'est pas le cas, c'est un signe qu'Amazon ajoute des backdoors, et c'est la pire contre publicité que je puisse imaginer. On est jamais trop prudent en ces temps de PRISM, mais vérifier aléatoirement à chaque build que 10% des binaires correspondent bien devrait être suffisant pour ne pas prendre de risque.
      - [^] # Re: Rebuild Debian
        
        Posté par Krunch (site web personnel) le 21 janvier 2014 à 16:19. Évalué à 3.
        
        Je préfère une impossibilité techniques à une « impossibilité » commerciale.
        
        pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
      - [^] # Re: Rebuild Debian
        
        Posté par khivapia le 21 janvier 2014 à 16:30. Évalué à 4.
        
        Sauf si le compilateur utilise des algorithmes nondéterministes à résultat possiblement variable.
        Il vaut mieux de toutes façons ne pas faire confiance à Amazon pour les binaires officiels.
      - [^] # Re: Rebuild Debian
        
        Posté par Étienne le 22 janvier 2014 à 15:55. Évalué à 10.
        
        On peut builder le même programme avec le même compilateur et les mêmes options sur le même OS et on devrait obtenir (si je ne m'abuse) le même résultat
        
        #include <stdio.h> int main() { printf(__TIME__); }

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.