Journal Encore des nouvelles de Fortran

32
6
mai
2021

Sommaire

Mon précédent article Des nouvelles de Fortran du 3 mai 2020 commençait par ces mots : « Punk is not dead, Fortran non plus ». Et voilà que dans le TIOBE Index d'avril 2021, le Fortran fait son retour dans le top 20 avec un saut de la 34e position à la 20e, après 10 ans d'éclipse. Avec un taux de 0,91 %, on pourrait se contenter de s'étonner et penser que l'on est dans le bruit. Mais je m'en vais démontrer que le T. Rex sait renouveler ses dents quand il s'agit de croquer les nombres (crunching numbers).

La communauté Fortran-lang

Bien que disposant d'un groupe de discussion Usenet depuis 1983 (comp.lang.fortran) et de quelques sites de référence tels que http://fortranwiki.org/, la galaxie des développeurs Fortran était plutôt éparpillée. La communauté Fortran-lang, créée il y a un an, vise à regrouper le maximum de personnes et de ressources autour de son site https://fortran-lang.org/ afin que Fortran dispose d'une communauté organisée comme d'autres langages plus récents. Elle est plus active que jamais, que ce soit sur son Fortran Discourse, lors des Monthly Calls (visioconférences mensuelles) ou sur GitHub. Un an après sa création, le Discourse comportait 201 membres actifs et 469 sujets comportant en tout 4500 messages. Les membres viennent de tous les horizons (de l'étudiant au membre du comité de normalisation Fortran) et de toutes les générations.

Les projets phares de la communauté sont :

  • le développement d'une bibliothèque standard de facto, stdlib, qui servira également de laboratoire pour proposer aux comités de normalisation WG5/J3 des implémentations de nouvelles fonctions.
  • Le compilateur LFortran dont je parlerai plus bas.
  • Le gestionnaire de paquets fpm (Fortran Package Manager) dont le développement a bien avancé (actuellement en version 0.2.0 alpha). Il s'inspire fortement de Cargo, le couteau suisse du langage Rust. Une fois installé (il est même disponible sur conda-forge), on peut en toute simplicité créer un projet, le compiler et le lancer :
$ fpm new projet
$ cd projet
$ fpm run

Il gère en particulier les dépendances, qu'il peut télécharger et compiler automatiquement depuis GitHub. Les projets Fortran utilisant fpm sont reconnaissables au fichier de configuration fpm.toml présent à leur racine. Associé à git clone, fpm a en particulier la vertu de permettre de tester un projet Fortran en trente secondes, par exemple pour tester le projet Object Based Interface to GnuPlot from Fortran (ogpf) :

$ git clone https://github.com/kookma/ogpf.git
$ cd ogpf
$ fpm run --example

Enfin, les principales pages du site Fortran-lang.org pourraient à terme être disponibles en français et en espagnol. Les traductions sont prêtes, mais l'internationalisation du site, basé pour l'instant sur Jekyll, demandera un travail conséquent reporté pour l'instant à plus tard.

Trois nouveaux compilateurs

Avec trois nouveaux compilateurs en cours de développement en même temps, tous basés sur LLVM, Fortran aborde avec une vigueur respectable une nouvelle décennie :

  • LFortran est développé par Ondřej Čertík (Los Alamos National Laboratory), cofondateur de la communauté Fortran-lang et membre du comité de normalisation J3. Le développement avance bien et le compilateur devrait cette année réussir à compiler du Fortran 95. Un des objectifs du projet est d'obtenir un compilateur permettant d'exécuter du Fortran de façon interactive dans Jupyter.

  • Fin décembre, Intel a rendu disponible pour tous gratuitement ses oneAPI Toolkits, qui incluent ses compilateurs Fortran. Au pluriel, puisqu'au classique ifort s'ajoute le nouveau compilateur ifx encore en version Bêta, basé quant à lui sur LLVM. À noter que, contrairement à ifort, il ne gère pas encore les co-tableaux (coarrays), une des fonctionnalités natives du langage permettant de faire du calcul parallèle.

  • Le développement du nouveau Flang, inclus dans LLVM, se poursuit, mais il n'est pas encore fonctionnel.

Événements à venir

GSoC 2021

La candidature de la communauté Fortran-lang a été acceptée pour le Google Summer of Code 2021. Le travail des étudiants inscrits accélérera en particulier les projets sus-cités.

FortranCon 2021

L' année dernière la communauté s'était retrouvée virtuellement à l'International Fortran Conference 2020 (FortranCon 2020). L'édition 2021 qui aurait dû avoir lieu au début de l'été a été repoussée à la rentrée de septembre.

Nouvelles diverses

Norme Fortran 202x

Le brouillon de la norme Fortran 202x (committee draft), qui succédera à Fortran 2018, devrait être figé en juillet 2021. Vous pouvez le consulter dans son état actuel (PDF). Les nouveautés sont détaillées dans l'introduction : des fonctions pour faciliter le passage des chaînes de caractères entre C et Fortran, des fonctions trigonométriques en degrés, des lignes de code source plus longues, de nouveaux descripteurs de format d'affichage, quelques améliorations pour le calcul parallèle, etc. La valeur de x n'est pas encore définie, mais une norme 202y est déjà prévue et les propositions des utilisateurs peuvent être déposées sur GitHub.

Page Fortran de Wikipedia

La page https://fr.wikipedia.org/wiki/Fortran s'offre depuis début mars une cure de jouvence : vérification de tous les liens, réorganisation et mise à jour du texte, nouvelles sections, etc. L'objectif est de présenter l'état actuel du Fortran, et non pas seulement son long passé.

Page Fortran du wiki ubuntu-fr

Idem pour la page Fortran du wiki ubuntu-fr, dont les trois dernières modifications dataient de 2015 et 2013. Vous y apprendrez entre autres comment installer OpenCoarrays pour faire de la programmation parallèle avec gfortran, comment installer les compilateurs Fortran gratuits d'Intel, comment installer le gestionnaire de paquets fpm, etc.

gtk-fortran 4.0

Après plus d'un de travail, le portage de gtk-fortran vers GTK 4, que je vous avais annoncé il y a un an, est terminé : gtk-fortran 4.0 est basé sur GTK 4.2 et GLib 2.68. Rappelons que gtk-fortran est une bibliothèque permettant de créer des interfaces graphiques GTK en Fortran moderne. Il permet également d'accéder à la bibliothèque généraliste GLib sur laquelle est basée GTK.

La documentation wiki du projet propose désormais deux tutoriels (en anglais). Un des objectifs pour l'année à venir est d'écrire d'autres tutoriels et d'améliorer la documentation du projet. Nous allons également explorer les possibilités du Fortran moderne : programmation orientée objet, cotableaux pour le calcul parallèle… Nous espérons également qu'à terme gtk-fortran pourra être utilisé sous forme de paquet fpm.

Conclusion

Le projet Fortran, proposé par John Backus en décembre 1953 à son supérieur chez IBM, fêtera donc la fin de sa septième décennie dans deux ans et demi. Il espère commencer sa huitième décennie avec une communauté dynamique et bien organisée, une librairie standard, trois nouveaux compilateurs et une nouvelle norme ISO.

Bibliographie

Articles des cofondateurs de la communauté Fortran-lang pour son premier anniversaire

Quelques bonnes références en Français pour apprendre le Fortran moderne

Quelques très bons livres récents en anglais

  • # Sérieusement ?

    Posté par  (site Web personnel) . Évalué à 6 (+4/-0).

    « […]des fonctions trigonométriques en degrés […] »

    Dans un langage pour des gens qui ne connaissent pas les mathématiques, ça ne m'aurait pas étonné. Mais en Fortran ?

    « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

    • [^] # Re: Sérieusement ?

      Posté par  (site Web personnel) . Évalué à 8 (+7/-0).

      Oui, personnellement, ça ne me manquait pas !

      J'ai trouvé l'argumentaire de la décision (16-10-2018) :
      https://j3-fortran.org/doc/year/18/18-272.txt

      Many, if not most, Fortran implementations support these degree-argument
      versions as extensions, and they are widely used. In the spirit of
      standardizing existing practice,
      we should add the following generic
      intrinsic functions to the standard: ACOSD, ASIND, ATAN2D…
      […]
      This provides a portable mechanism for programs that have
      mathematical formulas that need the actual degrees, and don't
      want the overhead of converting to/from radians.

      Plus étonnant, il y a même dans cette norme l'apparition de fonctions trigonométriques où les angles sont exprimés en multiples de \pi : ACOSPI, ASINPI, ATANPI, ATAN2PI, COSPI, SINPI, TANPI. Le message correspondant est intitulé "IEEE Circular trigonometric functions":
      https://j3-fortran.org/doc/year/19/19-204.txt

      On les retrouve dans un certain nombre de librairies mathématiques, par exemple :
      https://docs.oracle.com/cd/E19059-01/stud.10/819-0499/ncg_lib.html

      Ça doit répondre à des disciplines où exprimer ainsi les angles est une pratique courante.

      • [^] # Re: Sérieusement ?

        Posté par  . Évalué à 10 (+10/-0).

        Ça a aussi l'intérêt de pouvoir passer uniquement par des entiers. 90°, c'est un entier. \pi/2, c'est nécessairement un flottant, avec le risque d'erreurs d'arrondi qui s'y associe si tu commences par calculer la valeur de \pi/2 puis que tu appliques ta fonction trigonométrique au résultat. La plupart des angles sont exprimables en degrés avec un nombre fini de décimales, alors que \pi cumule les tares : il est irrationnel et même transcendant, ce qui te quasi-garantit qu'aucun angle pertinent ne sera jamais représentable en radians avec des entiers ou des flottants à nombre fini de décimales (que ce soit en base 2 ou 10).

        Ça, ce sont les sources. Le mouton que tu veux est dedans.

        • [^] # Re: Sérieusement ?

          Posté par  . Évalué à 3 (+1/-0).

          Oui, et surtout… il est bien plus facile de visualiser 90° que PI/2 rad. Ou est-ce PI/4? Je me souviens jamais, tellement j'utilise souvent les radians. Bon, je suis pas vraiment un matheux, je le reconnais.

          un flottant, avec le risque d'erreurs d'arrondi

          D'ailleurs, je me pose tout le temps la question, au point d'en être arrivé à fuir les flottants autant que faire se peut, c'est quoi qu'il faut utiliser pour tester une égalité? Je veux dire, la valeur qu'il faut utiliser pour dire "+- foo", c'est combien?

          PI cumule les tares : il est irrationnel

          C'est limite un truc que j'ai tendance à appliquer aux matheux de manière générale XD /me ->[]

          • [^] # Re: Sérieusement ?

            Posté par  (site Web personnel) . Évalué à 7 (+5/-0).

            À la fois quand on calcul une fonction trigonométrique, la seule façon rationnelle c'est d'utiliser les radians. Sinon il faut convertir.
            Par exemple cos(x) = 1-x²/2+x⁴/4!… si x est en unités naturelles d'angle uniquement, donc en radians. Du coup, la valeur de pi intervient pour tous les calculs… où l'argument de la fonction n'est pas exprimé en radians.
            Et par ailleurs le Fortran est tout de même un peu destiné à des gens n'ayant pas encore oublié le programme de mathématique de collège : le rapport du périmètre d'un cercle à son diamètre est nommé pi ; et un angle se mesure naturellement par le rapport de la longueur d'un arc de cercle qu'il embrasse à un rayon de ce cercle.

            « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

            • [^] # Re: Sérieusement ?

              Posté par  . Évalué à 3 (+2/-1).

              des gens n'ayant pas encore oublié le programme de mathématique de collège

              Justement. Au collège, je ne savais même pas qu'il existait d'autres unité d'angles que le degré.

              • [^] # Re: Sérieusement ?

                Posté par  . Évalué à 3 (+1/-0).

                J'oubliais:

                À la fois quand on calcul une fonction trigonométrique, la seule façon rationnelle c'est d'utiliser les radians. Sinon il faut convertir.

                Et les conversions, c'est irrationnel?
                Pour moi, ce qui est irrationnel, c'est d'optimiser avant d'avoir un code lisible et facile à comprendre.
                Hors, je trouve qu'il est plus simple de comprendre:

                aim.angle += 45;
                if ( aim.angle == 90 ) then
                 ...
                end if

                que

                aim.angle += PI / 4;
                if ( abs( aim.angle - PI / 2 ) <= epsilon( aim.angle ) ) then
                  ...
                end if

                Bon, évidemment, ça va dépendre du domaine, mais ce bout de code tout à fait rencontrable dans la vie réelle (peut-être pas actuellement avec fortran, mais justement, fortran n'est pas vraiment le langage le plus simple à rencontrer je dirais). Toute ressemblance directe avec un truc sur lequel je bosse est purement fortuite, bien sûr.

                J'ai essayé en fortran, pas l'habitude, désolé si la syntaxe est pas bonne. Je me suis "inspiré" (méchamment copié à ce stade) d'un stackoverflow sur la très célèbre question de la comparaison des flottants, version fortran.

                • [^] # Re: Sérieusement ?

                  Posté par  (site Web personnel) . Évalué à 4 (+3/-0). Dernière modification le 07/05/21 à 12:28.

                  J'ai essayé en fortran, pas l'habitude, désolé si la syntaxe est pas bonne. Je me suis "inspiré" (méchamment copié à ce stade) d'un stackoverflow sur la très célèbre question de la comparaison des flottants, version fortran.

                  L'effort est apprécié !

                  Juste pour information, je précise pour le lecteur intéressé par Fortran :
                  1. le séparateur est le passage à la ligne, donc pas de ; en fin de ligne en Fortran. Par contre, il peut éventuellement être utilisé pour séparer plusieurs instructions sur une même ligne.
                  2. L'opérateur += n'existe pas en Fortran.
                  3. Le séparateur pour les structures est le % : on écrirait aim%angle
                  4. Le test d'égalité est bien le ==. On peut aussi rencontrer l'ancienne syntaxe .eq.
                  5. Il est effectivement déconseillé, sauf exception, en calcul numérique d'utiliser ce test d'égalité avec des réels flottants, puisque les arrondis s'accumulant au fil des calculs, il y a généralement peu de chances qu'on tombe pile-poil sur la valeur prévue, c'est-à-dire avec environ 16 décimales exactes (ou 53 bits en binaire). Les compilateurs Fortran afficheront d'ailleurs en général un avertissement pour un tel test.

                  Dans un ton à peine provocateur, le calcul numérique c'est l'art d'obtenir un résultat valable en calculant faux. Car même en s'en tenant à des additions, avec les réels informatiques l'associativité de l'addition vole en éclat et en règle générale :

                   a+(b+c) \ne (a+b)+c

                  Par exemple, si on somme des nombres de grandeur variable, on aura alors intérêt à faire la somme du plus petit au plus grand, plutôt que l'inverse, pour limiter les erreurs d'arrondis. De quoi s'amuser…

                  • [^] # Re: Sérieusement ?

                    Posté par  . Évalué à 3 (+1/-0).

                    Juste pour information, je précise pour le lecteur intéressé par Fortran :

                    Merci pour les correctifs!

                    1. Il est effectivement déconseillé, sauf exception, en calcul numérique d'utiliser ce test d'égalité avec des réels flottants,

                    C'est valable pour tous les langages, en fait. C'est quoi déjà… la norme IEEE? Un truc du genre? Bref, avec laquelle il faut éviter ce genre de choses.

                    Les compilateurs Fortran afficheront d'ailleurs en général un avertissement pour un tel test.

                    Idem pour C et C++, mais bon, c'est peut-être plus récent, ça ne serait pas surprenant.

                    le calcul numérique c'est l'art d'obtenir un résultat valable en calculant faux.

                    De toute manière, une fois qu'on passe dans le monde réel, les résultats sont systématiquement approximés quand il y a trop de chiffres. De mémoire, la notation ingénieur qu'on m'apprenais au lycée était du genre: 123,45 * 10^6.
                    Le souci, c'est qu'a ma connaissance, peu de langages ont un opérateur et un typage adapté aux flottants (en vrai, à ma connaissance, aucun, mais elle est si limitée qu'elle est sûrement fausse, j'ai donc approximé en "peu" à la place :p).

                    • [^] # Re: Sérieusement ?

                      Posté par  (site Web personnel) . Évalué à 3 (+2/-0). Dernière modification le 07/05/21 à 12:58.

                      Oui, c'est valable pour tous les langages qui calculent avec des flottants.
                      La norme c'est IEEE 754
                      Il faut une norme pour qu'un même calcul donne le même résultat sur n'importe quel microprocesseur.

                      Le problème, c'est qu'en règle générale on sait que le résultat est arrondi, mais on ne sait pas combien de chiffres sont faux. Il y a des gens qui ont travaillé sur des librairies (et des processeurs ?) qui seraient capable de fournir non pas un résultat arrondi, mais un encadrement du résultat entre deux bornes.

                      Bien sûr, généralement ça se passe bien, seuls les derniers chiffres seront faux. Et par exemple, un ingénieur se contentera souvent d'un nombre de chiffres significatifs faible. Mais il y a des cas pathologiques.

                      Et même si ça se passe bien, plus les calculs s'enchaînent et plus on accumule les arrondis. Avec un processeur qui fait quelques milliards de calculs par seconde, il faut donc être conscient de la façon dont ça fonctionne.

                      Une petite citation à méditer :

                      « Les Shadoks avaient entendu dire que plus un ordinateur va vite, plus il donne de bons résultats. »
                      Les Shadoks et le Désordinateur, Jacques Rouxel, 2000.

                • [^] # Re: Sérieusement ?

                  Posté par  (site Web personnel) . Évalué à 3 (+1/-0).

                  Hors, je trouve qu'il est plus simple de comprendre […] if ( aim.angle == 90 )

                  Perso je trouve qu'il est plus simple de comprendre if ( .false. ).
                  (What every computer scientist should know about floating-point arithmetic)

                  Adhérer à l'April, ça vous tente ?

              • [^] # Re: Sérieusement ?

                Posté par  (site Web personnel) . Évalué à 5 (+3/-0).

                Au collège, je ne savais même pas qu'il existait d'autres unité d'angles que le degré.

                Lequel ? Le sexagésimal ou le centésimal :-) ?

                Le toolkit Atlas, la bibliothèque légère et facile à utilser pour débuter avec la programmation d'interfaces graphiques… (voir 'site Web personnel").

              • [^] # Re: Sérieusement ?

                Posté par  . Évalué à 3 (+3/-1).

                des gens n'ayant pas encore oublié le programme de mathématique de collège

                Justement. Au collège, je ne savais même pas qu'il existait d'autres unité d'angles que le degré.

                Ça fait longtemps… et je ne sais plus à quels niveaux on introduit les différentes unités d'angles. Mais tel Jourdain faisant de la prose à son insu, nous utilisons le radian d'angle sans le savoir : (plus précisément par demi-radian et non par degrés quand on raisonne en tours…) tour complet, demi tour, quart de tour à gauche ou à droite, et les rares fois qu'on utilise d'autres fractions de tour.

            • [^] # Re: Sérieusement ?

              Posté par  . Évalué à -1 (+3/-6).

              Et par ailleurs le Fortran est tout de même un peu destiné à des gens n'ayant pas encore oublié le programme de mathématique de collège : le rapport du périmètre d'un cercle à son diamètre est nommé pi

              Eh non ! C'est le rapport entre le périmètre d'un cercle et son rayon qui est nommé \pi. Sinon, un tour complet ferait \pi radians, or il fait 2\pi radians.

              C'est exactement le genre de choses sur lequel on a tendance à faire des erreurs idiotes en radians, et pas en degrés. Probablement une question d'habitude : le degré est tellement utilisé dans la vie courante qu'on l'utilise sans y penser et on se familiarise en permanence avec.

              Ça, ce sont les sources. Le mouton que tu veux est dedans.

              • [^] # Re: Sérieusement ?

                Posté par  . Évalué à 6 (+4/-0).

                Tu confonds rayon et diamètre.

                • [^] # Re: Sérieusement ?

                  Posté par  . Évalué à 3 (+1/-0).

                  Mouarf, autant pour moi. Bon ben pan sur le bec, ça m'apprendra à donner des leçons.

                  Ça, ce sont les sources. Le mouton que tu veux est dedans.

              • [^] # Re: Sérieusement ?

                Posté par  . Évalué à 4 (+2/-0).

                En même temps quand on en est rendu à compter les tours en degrés comme ils le font dans les sports style skate ou Snow Board, les 1080° et compagnie perso ça me parle pas :) peut-être que les multiples de 2π ça serait sans doute plus pratique : « il a fait un 5π !! » (2,5 tours)

              • [^] # Re: Sérieusement ?

                Posté par  . Évalué à 5 (+4/-0). Dernière modification le 07/05/21 à 15:25.

                ???
                J'ai pas compris: si r est le rayon, le diamètre d est égal à 2r et le périmètre est égal 2πr (ou πd)
                π c'est bien le rapport du périmètre d'un cercle à son diamètre
                (vu que tu as été plussé, je me dis qu'il y a un truc qui m'a échappé dans ton message)

              • [^] # Re: Sérieusement ?

                Posté par  . Évalué à 1 (+0/-0).

                L'autre erreur ayant été déjà évoquée, je n'en rajouterai pas une couche.

                on a tendance à faire des erreurs idiotes en radians, et pas en degrés. Probablement une question d'habitude : le degré est tellement utilisé dans la vie courante qu'on l'utilise sans y penser et on se familiarise en permanence avec.

                Ah tiens, je venais juste de répondre le contraire en écrivant :

                Mais tel Jourdain faisant de la prose à son insu, nous utilisons le radian d'angle sans le savoir : (plus précisément par demi-radian et non par degrés quand on raisonne en tours…) tour complet, demi tour, quart de tour à gauche ou à droite, et les rares fois qu'on utilise d'autres fractions de tour.

                …ou alors nous ne côtoyons pas la même vie courante ?

          • [^] # Re: Sérieusement ?

            Posté par  . Évalué à 5 (+3/-0).

            D'ailleurs, je me pose tout le temps la question, au point d'en être arrivé à fuir les flottants autant que faire se peut, c'est quoi qu'il faut utiliser pour tester une égalité? Je veux dire, la valeur qu'il faut utiliser pour dire "+- foo", c'est combien?

            La théorie c'est que pour voir si x et y, deux flottants, sont "égaux", c'est qu'il faut voir si la valeur absolue de leur différence est inférieure à un seuil. Donc techniquement, il suffit de faire:

            abs(x-y) < seuil

            La seule question en suspend est de trouver le seuil. Sauf que là, ça va dépendre de ce que tu cherches. Si tu connais les ordres de grandeur de x et y attendus, et que tu as une idée de ce que tu tolères ou que tu peux calculer le nombre de bit de bruit introduit par les arrondis des calculs, tu peux facilement calculer un seuil.

            Si tu ne connais pas les valeurs attendues (ni x, ni y ne sont constants, et tu ne connais pas le phénomène physique derrière), tu peux remplacer cela par un seuil relatif, quelque chose comme

            abs(x-y)/y < seuil

            Et tu choisis seuil en fonction du type de flottant que tu utilises. Sauf que là, il va falloir aussi gérer les cas où y == 0, ou proche de 0, qui peuvent provoquer des NaN, Inf, ou des overflows…

            Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

            • [^] # Re: Sérieusement ?

              Posté par  . Évalué à 2 (+0/-0).

              Bref, c'est une galère?

              • [^] # Re: Sérieusement ?

                Posté par  . Évalué à 3 (+1/-0).

                Oui, mais c'est ça qui est intéressant quand on fait du calcul numérique.

                • [^] # Re: Sérieusement ?

                  Posté par  (site Web personnel) . Évalué à 1 (+0/-0).

                  Oui, c'est ça qui est fun. C'est comme faire du surf ou du ski, ou faire le funambule.

                  C'est aussi pour ça que les banques ne travaillent pas en Fortran, en tout cas pas pour tenir les comptes… Sinon tu serais sûrement payé quelque chose comme XXXX,9999999999985 €/mois ou XXXX,00000000013 €/mois
                  :-)

                  • [^] # Re: Sérieusement ?

                    Posté par  (site Web personnel) . Évalué à 4 (+1/-0).

                    Exemple d'actualité récente sur du financier : https://tech.slashdot.org/story/21/05/05/1454246/berkshire-hathaways-stock-price-is-too-much-for-computers (une action trop chère pour être gérée)

                    • [^] # Re: Sérieusement ?

                      Posté par  (site Web personnel) . Évalué à 2 (+1/-0). Dernière modification le 07/05/21 à 17:04.

                      Ca me fait penser qu'on vit dans un monde supposé linéaire. C'est la fin de l'histoire : plus d'épidémies, plus d'épisodes d'hyperinflation, etc. Il ne peut plus rien se passer…

                      Si on devait un jour sortir un billet d'un million d'euros pour acheter son pain, on peut supposer que les logiciels bancaires seraient HS. Les développeurs écrivent les préjugés de leur époque dans leur code.

                      • [^] # Re: Sérieusement ?

                        Posté par  . Évalué à 3 (+1/-0).

                        "2 caractères pour l’année devraient largement suffire pour la durée de vie de ce logiciel". You only live your century once.

                    • [^] # Re: Sérieusement ?

                      Posté par  . Évalué à 2 (+1/-0).

                      https://docs.python.org/fr/3/library/decimal.html

                      (dans le bancaire c'est le Cobol qui a cours)

                  • [^] # Re: Sérieusement ?

                    Posté par  . Évalué à 2 (+1/-0).

                    Blague à part, les soucis du calcul flottant ne sont pas propre au FORTRAN ; tu les retrouves aussi dans du COBOL ou du Java ou du C++ etc. Tous les langages sans exception.

                    Quand tu fais du calcul comptable/financier, que ce soit en FORTRAN ou dans n'importe quel autre langage, tu utilises du calcul/stockage en « décimales fixes » (quitte à stocker en chaîne de caractères et passer par des entiers pour les calculs si le type décimal n'est pas nativement supporté par le langage.)

                    Au passage, ceci n'empêche pas les banques et les logiciels de comptabilité de faire des erreurs d'arrondi (vécus.)

        • [^] # Re: Sérieusement ?

          Posté par  . Évalué à 5 (+3/-0).

          ce qui te quasi-garantit qu'aucun angle pertinent ne sera jamais représentable en radians avec des entiers ou des flottants à nombre fini de décimales

          Bah il y a 0 quand même, qui est un angle relativement courant, qui est représentable. Bon ok, je sors.

          Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

      • [^] # Re: Sérieusement ?

        Posté par  . Évalué à 1 (+3/-2).

        Pi is overrated… Vive tau!

        https://tauday.com/tau-manifesto

  • # Option -static-libgfortran

    Posté par  . Évalué à 5 (+3/-0).

    Super article ! Merci !

    Sur le wiki ubuntu-fr.org tu parles de l'option -static-libgfortran. Qu'est-ce qu'elle apporte par rapport à -static ?

    • [^] # Re: Option -static-libgfortran

      Posté par  (site Web personnel) . Évalué à 6 (+5/-0). Dernière modification le 06/05/21 à 17:31.

      Le -static-libgfortran m'a été susurré par un développeur de gfortran. Je l'ai testé sur un petit algorithme de calcul de Pi par Monte Carlo et voici ce que j'obtiens en temps de calcul et en taille d'exécutable en fonction des drapeaux :

      normal : 20,1 s ; 17 ko
      -static : 19,4 s ; 1,3 Mo
      -static-libgfortran : 18,8 s ; 287 ko

      Apparemment, ça embarque moins de choses dans l'exécutable, mais c'est un peu plus rapide (-3 %, c'est modeste mais c'est toujours ça de gagné quand c'est long). J'ai cru comprendre que le -static-libgfortran permettait d'embarquer les fonctions intrinsèques du langage situées dans libgfortran comme RANDOM_NUMBER() que j'utilise dans mon test. Donc pour cette librairie c'est en static et pour les autres en shared.

      J'ai trouvé ça, mais c'est un peu court jeune homme :
      https://gcc.gnu.org/onlinedocs/gfortran/Link-Options.html#Link-Options

      Je vais demander à la personne de m'expliquer plus précisément les choses. Et je posterai si j'ai une réponse claire.

      Après, bien sûr, ça améliore les choses sur ce programme-là, mais ça n'est pas forcément une loi générale. A tester pour chaque programme, comme c'est souvent le cas en optimisation.

      • [^] # Re: Option -static-libgfortran

        Posté par  . Évalué à 4 (+2/-0).

        Merci pour la réponse.
        Dés que je pourrai, je testerai pour voir si c'est compatible avec OpenMP. L'option -static, elle, ne l'est pas.

        Sur les tests automatiques d'un code que je compile d'habitude avec -static la taille de l'exécutable a un peu diminué, en gros 25%. Je n'ai pas vu de gain de performance sensible, un peu plus long sur certains tests, un peu plus rapide sur d'autres. Mais il faudrait répéter les tests et faire des moyennes pour avoir une vraie mesure.

        • [^] # Re: Option -static-libgfortran

          Posté par  (site Web personnel) . Évalué à 2 (+1/-0). Dernière modification le 06/05/21 à 18:17.

          Oui, -static-libgfortran fonctionne avec mon exemple OpenMP. En ce moment je commence à explorer les coarrays et autres routines collectives, et j'ai créé un dépôt pour faire des tests (mais je n'utilise pas -static-libgfortran dans mes comparatifs pour rester simple) :
          https://github.com/vmagnin/exploring_coarrays

          Sur Pi Monte Carlo, gfortran+OpenMP est gagnant. Mais on peut penser que les compilateurs Fortran vont continuer de s'améliorer avec les coarrays, les cosum, etc. La version avec co_sum n'est pas loin derrière OpenMP.

    • [^] # Re: Option -static-libgfortran

      Posté par  (site Web personnel) . Évalué à 2 (+1/-0).

      Petite expérimentation :

      $ gfortran pi_monte_carlo_serial.f90
      $ ldd ./a.out
              linux-vdso.so.1 (0x00007fff4dde4000)
              libgfortran.so.5 => /usr/lib/x86_64-linux-gnu/libgfortran.so.5 (0x00007fa0ce2c7000)
              libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa0ce0dd000)
              libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007fa0ce093000)
              libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fa0cdf44000)
              libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fa0cdf29000)
              /lib64/ld-linux-x86-64.so.2 (0x00007fa0ce5d3000)
      $ gfortran -static pi_monte_carlo_serial.f90
      $ ldd ./a.out
              n'est pas un exécutable dynamique
      $ gfortran -static-libgfortran pi_monte_carlo_serial.f90
      $ ldd ./a.out
              linux-vdso.so.1 (0x00007ffc591d5000)
              libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f634bde0000)
              libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007f634bd96000)
              libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f634bc47000)
              libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f634ba5d000)
              /lib64/ld-linux-x86-64.so.2 (0x00007f634be7b000)

      On voit que -static-libgfortran a bien pour effet de ne lier en static que la libgfortran. Les autres le sont en shared.

      On peut se faire une idée de ce qu'il y a dedans avec :

      $ strings -n 7 /usr/lib/x86_64-linux-gnu/libgfortran.so.5 | more

      Est-ce qu'il y a une commande plus élégante pour lister les fonctions contenues dans une librairie ?

      • [^] # Re: Option -static-libgfortran

        Posté par  (site Web personnel) . Évalué à 3 (+2/-0).

        Est-ce qu'il y a une commande plus élégante pour lister les fonctions contenues dans une librairie ?

        readelf --syms /usr/lib/x86_64-linux-gnu/libgfortran.so.5 te donnera la liste des symboles. De plus, contrairement à ldd, readelf ne fait que lire et pas résoudre les dépendances.

  • # Coquilles

    Posté par  . Évalué à 6 (+5/-0).

    J'ouvre un fil pour les coquilles, parce que ça sent la promotion en dépêche à plein nez :

    "Le développement du nouveau Flang, inclue dans LLVM"
    -> "Le développement du nouveau Flang, inclus dans LLVM"

    • [^] # Re: Coquilles

      Posté par  . Évalué à 2 (+1/-0).

      Je poursuis avec les accents, comme par exemple dans la partie des « Trois nouveaux compilateurs »

      Fin décembre, Intel a rendu disponible gratuitement pour tous ses oneAPI Toolkits, qui incluent ses compilateurs Fortran. Au pluriel, puisqu'au classique ifort s'ajoute le nouveau compilateur ifx encore en version Bêta, basé quant à lui sur LLVM. A noter que, contrairement à ifort, il ne gère pas encore les co-tableaux (coarrays), une des fonctionnalités natives du langage permettant de faire du calcul parallèle.

      …où c'est « À noter que » au lieu de « A noter que ».
      …de même, je pense que, dans « Intel a rendu disponible gratuitement pour tous ses oneAPI Toolkits », il manque un bout.

  • # Nostalgie

    Posté par  . Évalué à 10 (+15/-0).

    Vers fin 1964, j'écrivais mes premières lignes de FORTRAN sur une IBM 1620, c'était lors de mes études d'ingénieur en génie électrique. Les résultats sortaient sur la machine à écrire qui servait d'E/S à la bécane, conjointement à un lecteur et un perforateur de ruban perforé.
    Les seuls formats admis : I, F, E, on arrivait à obtenir des colonnes de chiffres, sans en-têtes (ensuite il est venu un compilateur appelé FORTRAN SAY, qui permettait au moins de mettre des titres.

    Une fois mon diplôme obtenu, en 1966, j'ai quitté l'électricité pour consacrer toute ma carrière à ce qui était l'EDP (Electronic Data Processing) est qui est devenu l'informatique.
    Je ne l'ai jamais regretté.
    Au début, mes condisciples me mettaient en garde : tu t'engages sur une voie de garage, dans dix ans au plus les ordinateurs se programmeront eux-même. Mais, après quelques années, lorsqu'ils comparaient mes revenus avec les leurs, ils commençaient à penser que la voie de garage était assez séduisante.

    En fait, indépendamment de l'aspect financier, je me suis amusé à programmer toute ma vie dans le domaine du logiciel embarqué et du traitement du signal, j'étais bien rémunéré pour me faire plaisir, quoi de mieux.

    • [^] # Re: Nostalgie

      Posté par  (site Web personnel) . Évalué à 7 (+6/-0).

      :-)

      dans dix ans au plus les ordinateurs se programmeront eux-même.

      Voilà un serpent de mer qui est plus vieux que je ne pensais !

  • # Fortran newsletter: May 2021

    Posté par  (site Web personnel) . Évalué à 1 (+0/-0).

    La dernière newsletter mensuelle vient de paraître :
    https://fortran-lang.org/newsletter/2021/05/01/Fortran-Newsletter-May-2021/

    Vous y trouverez les dernières évolutions des projets de la communauté, des nouvelles du développement des compilateurs Flang et LFortran, et la vidéo du dernier Fortran Monthly Call.

  • # coArrays vs. OpenMP

    Posté par  . Évalué à 3 (+1/-0).

    Je n'ai jamais encore joué avec les coArrays, il faudrait que je m'y mette, mais j'ai l'impression que ce n'est pas du tout la même granularité que OpenMP.
    J'essaierai peut-être sur une analyse de sensibilité automatique type Monte-Carlo.

Envoyer un commentaire

Suivre le flux des commentaires

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