Comme annoncé dans la dépêche de 2013, cette année les concours de recrutement des professeurs agrégés de mathématiques (agrégation interne et externe de Mathématiques) n'utilisent plus que des logiciels libres.
Depuis quelques années, les concours se passent sur ClefAgreg, une clef USB « live » téléchargeable et autonome, fonctionnant désormais indifféremment sur PC ou sur Mac (intel). Cette clef autonome peut se personnaliser via l'ajout d'extensions (images sqh dans les faits). Elle a notamment été la source de la clef ISN, distribuée aux enseignants lors de la création de l'option Informatique et Sciences du Numérique dans les classes de Terminale scientifique..
Fonctionnant d'abord sur des machines Windows / Linux avec 4 logiciels dont 3 propriétaires, l'agrégation externe aura donc abandonné Windows en 2007 puis les logiciels propriétaires en 2015. Il est possible de télécharger une clef reproduisant l'environnement depuis 2007. L'agrégation interne a introduit l'utilisation de logiciels vers 2010 et le concours se déroule depuis lors sur ClefAgreg.
Les logiciels proposés sont, pour le concours externe :
- Maxima (avec wxmaxima) ;
- Sage ;
- R (avec RStudio[1] ) ;
- Scilab ;
- Octave ;
- Xcas (avec Qcas) ;
- Ocaml, Camllight, Python, C et Java pour la programmation.
et pour l'agrégation interne
- Geogebra et Carmetal ;
- Libreoffice ;
- Maxima ;
- Scilab, Octave et freemat ;
- Xcas (avec Qcas) ;
- Freepascal, python, Java et C pour la programmation ;
- GeoPlan et Geospace via l'utilisation de wine ;
- Sage est proposé en essai.
L'environnement retenu est toujours XFCE, la clef actuelle est sous Debian (comme c'est le cas depuis longtemps) version Wheezy, le noyau est un 3.15-6.
[1] Rstudio a une licence particulière AGPL qui impose la diffusion des source en cas d'utilisation via Internet. Contrairement à l'AGPLv3 compatible avec la GPLv3, l'AGPL est incompatible avec la GPL.
Aller plus loin
- Agrégation interne (142 clics)
- Agrégation externe (152 clics)
- ClefAgreg (260 clics)
# On y est presque
Posté par lolop (site web personnel) . Évalué à 6.
Manque plus que l'installation de Linux à la place de Windows dans les collèges et lycées ;-)
(et d'un peu de formation pour tous les autres enseignants)
World Domination !
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: On y est presque
Posté par Professeur Méphisto . Évalué à 3.
ton optimisme fait plaisir à voir
[^] # Re: On y est presque
Posté par Kerro . Évalué à 4.
Nan, c'est du second degré puisqu'il précise ensuite qu'il faut de la formation :-)
# Félicitation
Posté par sv0t . Évalué à 4.
Cela fait des années que je suis tes travaux, félicitation pour l'opiniâtreté et la patience avec laquelle ce projet c'est imposé, et à détrôné les logiciels propriétaire d'un concours national.
# Agrégation....pas toutes
Posté par falcaf . Évalué à 1.
En musique, l'an passé au concours interne, si les ordinateurs étaient toujours sous windows, il y avait quand même audacity pour la musique et peut-être même vlc, je crois, pour d'éventuels documents video ; par contre, pour réaliser une présentation, pas de libreoffice mais le machin proprio habituel…ce qui est curieux et désavantage les candidats linuxiens. Bon, je ne suis pas sûr qu'il s'en trouve beaucoup, je serais même surpris qu'il y en ait un seul ! :(
cordialement,
[^] # Re: Agrégation....pas toutes
Posté par François Boisson . Évalué à 3.
Il ne faut pas aller plus vite que… la musique justement (involontaire au démarrage).
Les logiciels libres sont fondés sur le principe que ce qui fait la valeur d'un système informatique n'est pas constituée des logiciels brutes mais de leur utilisation. La valeur d'une base de données est plus liée au trvail nécessaire à sa mise en place, à l'élaboration de sa structure et à la préparation des requêtes qu' à mysql, mariadb, postgresql, etc. Un logiciel est donc gratuit (entre autres) et, si on accepte de travailler, on peut l'exploiter à fond. Si on veut du travail prémaché (en clair une base clefs en main, ou de la documentation parfaite, là on exige un travail conséquent et donc le rémunérer n'est pas scandaleux.
Les professeurs enseignants actuels ont investi énormément de leur temps à assimiler et utiliser complètement des logiciels divers dont des logiciels propriétaires. Les accros aux logiciels propriétaires, dénigrés aujourd'hui, sont les mêmes qui il y a 20 ans ont investi du temps (beaucoup) et de l'argent (beaucoup aussi) pour faire bénéficier leurs élèves de l'outil informatique. On peut comprendre qu'ils n'aient pas envie de recommencer un tel investissement surtout en cette période d'évolution du métier.
Il suffit d'attendre, ça va venir..
# Logiciels libres
Posté par InsideLoop . Évalué à 3. Dernière modification le 07 avril 2015 à 11:22.
En tant qu'agrégé de mathématiques et ancien professeur de mathématiques (et d'informatique) en classes préparatoires, je ne peux que féliciter cette initiative. Le seul problème reste celui de la qualité des logiciels libres. Et là, il faut faire le tri, ce qui est toujours le problème avec les logiciels libres. Les logiciels à retenir sont à mon avis :
Le reste est à mon avis à oublier. Malheureusement, il n'existe aucun logiciel de calcul formel "utilisable" en logiciel libre (j'ai des exigences que beaucoup qualifient d'élevées). Sage est une usine à gaz comme personne n'a osé inventer avant et seul Maxima me semble digne d'intérêt. Malheureusement, la documentation des ces logiciels laisse toujours à désirer et on est à des années lumières des solutions propriétaires comme Mathematica. Je préfère rester poli et ne pas parler d'XCas qui est certes un projet sympathique mais qui n'a aucun avenir international.
En numérique, Scilab, bien qu'étant très aboutit, reste très franco-français (voire franco-chinois) et me semble en bien mauvaise posture face à un écosystème python qui est utilisé internationalement.
Il serait bon de selectionner et de mettre les réussites libre en avant et de trier. Je sais qu'en classes préparatoires, la mention de Scilab a été ajoutée au dernier moment, juste pour faire plaisir à certains de l'INRIA. Ou comment saper un programme qui se base essentiellement sur Python et introduire un doute dans la tête des profs de prépas. Cela manque terriblement de responsabilité.
[^] # Re: Logiciels libres
Posté par jyes . Évalué à 5.
Puisqu’on a affaire à un connaisseur, je suis surpris de ne voir aucune mention d’Octave dans ce commentaire. Comme alternative à Matlab il semble un excellent candidat puisqu’il est très compatible avec ce dernier et en partage la syntaxe. De plus, bien que je trouve cela plutôt contre-productif à titre personnel, les dernières versions se dotent d’un environnement graphique qui devrait rassurer les moins barbus. Est-ce par oubli, par méconnaissance de cet outil ou à cause de ses défauts qu’il est absent de ce tour d’horizon. Si c’est la troisième option, je serais intéressé par une critique plus en détail de ceux-ci. Merci ;-)
[^] # Re: Logiciels libres
Posté par InsideLoop . Évalué à 1. Dernière modification le 07 avril 2015 à 14:06.
Je rangerai Octave dans la même catégorie que Scilab : un logiciel bien fait, mais qui ne fait pas le poids en terme d'utilisateurs face à la communauté Python/Numpy. Dans le logiciel scientifique libre, seul R a pris une place conséquente face à Python (quasiment tous les statisticiens l'utilisent). Ce qu'on oublie souvent, c'est que pour un tel logiciel soit bon, il faut un support de bonne qualité et notamment des bons livres. Ici encore, Python et R dominent. Un livre comme celui-ci http://www.amazon.com/Introduction-Statistical-Learning-Applications-Statistics/dp/1461471370/ref=sr_1_1?ie=UTF8&qid=1428407657&sr=8-1&keywords=statistical+learning+R n'existe pas pour Octave. Je sais bien qu'on peut adapter, mais cela facilite tellement la compréhension de parler le même langage.
C'est un peu comme OCaml. C'est bien gentil d'enseigner OCaml a des élèves de prépa, mais soyons réalistes. Qui utilise OCaml ? Je sais bien qu'on l'a utilisé pour vérifier la cabine de pilotage de l'A380 et LLVM peut même se contrôler par l'intermédiaire d'OCaml. Même Microsoft qui l'a rendu compatible avec .NET en le renommant F# ils n'arrivent pas le pousser en dehors des mathématiques financières où il vivote. J'ai vu tellement d'élèves sortir de prépa penser que bonne programmation informatique rimait avec récursivité pour tous les problèmes, que je crois qu'il est temps d'utiliser des outils utilisés par une proportion significative des personnes. Pour cette raison, je crois que Python est un bon choix dans l'enseignement de l'informatique pour tous et je suis ravi qu'il ait été adopté.
[^] # Re: Logiciels libres
Posté par anaseto (site web personnel) . Évalué à 3.
L'important est plutôt quel est l'objectif du cours et quelles sont les notions à aborder. Si c'est juste apprendre le langage qu'il y a le plus de chances qu'ils utilisent plus tard, OCaml n'est probablement pas un bon choix. En fait, je ne suis même pas sûr que Python soit le meilleur choix, je n'ai aucune idée de quel est le langage de programmation le plus utilisé, peut-être javascript, ou peu importe, je ne trouve pas que ce soit le plus important pour apprendre, un langage en soi s'apprend assez vite. Je dirais même, à chaque langage d'un nouveau type que l'on découvre, on devient un meilleur programmeur dans les autres langages que l'on connaît déjà, et plus on en connaît, plus en apprendre de nouveaux est facile, donc essayer de se cantonner à un seul langage choisi pour des raisons statistiques ne me semble pas pertinent.
S'il s'agit de leur apprendre des bases d'algorithmique, parcours d'arbres et parcours de graphes, etc. OCaml est un excellent choix : sans s'encombrer avec des détails trop bas niveau comme en C, ils disposent quand même d'un bon système de types qui permet de décrire des structures de données complexes facilement, et d'un langage qui permet tant d'écrire de façon récursive qu'impérative au besoin ; la plupart des algos impératifs des livres se traduisent très bien en OCaml tels quels.
Tu écris plus haut :
Ce qui m'inquiète avec ce genre de raisonnements, c'est que tu sous-entends que les profs ne doivent pas connaître plus d'un langage de programmation non plus ; mais si eux n'ont pas une vision plus large, j'ai peur de la vision étriquée de la programmation qui peut en ressortir.
Une autre phrase qui me surprend un peu, plus haut :
Tu te places dans quel contexte, ton utilisation personnelle, ou celle des étudiants ? Parce que s'il s'agit du point de vue des étudiants, tes exigences ne sont plus si importantes peut-être, et tant Maxima comme Sage font parfaitement l'affaire à mon avis, parce qu'ils seront loin de toutes façons d'avoir besoin de ces langages à un niveau ou leurs limites seraient importantes au cours de l'apprentissage et, plus tard, quand ils seront "grands", ils auront le temps de changer de logiciel s'ils en ont besoin. Pour apprendre, l'« avenir international » n'a aucune importance. Enfin, peut-être que Mathematica est très bon (je ne l'ai jamais utilisé), mais pour avoir vu des gens se servir de Maple, je peux dire que l'herbe n'est pas toujours plus verte ailleurs, parce que des programmes qui marchent pas parce que le code est passé en italique… (c'est stocké en xml) bref, ce logiciel a de quoi dérouter celui qui le découvre, sans qu'on aille chercher des fonctionnalités avancées.
[^] # Re: Logiciels libres
Posté par lasher . Évalué à 3.
D'accord avec la majorité de ce que tu dis. Cependant :
Ce qu'il disait plus haut était que Sage & co. sont trop compliqués à utiliser comparés à Mathematica (ou Maple je suppose). Lorsque j'étais en école d'ingé, j'utilisais un truc appelé Mupad (en ligne de commande, car il existait une version gratuite non-commerciale pour les étudiants). Pour nos besoins c'était suffisant, mais c'était aussi très simple d'utilisation. Je n'ai jamais utilisé Sage; peux-tu dire la même chose à son propos ?
[^] # Re: Logiciels libres
Posté par anaseto (site web personnel) . Évalué à 4.
Je suppose que ça doit dépendre du domaine d'utilisation, parce que, en effet, le calcul formel c'est assez vaste. Perso, je l'ai utilisé il y a deux ans pour faire des manipulations dans des anneaux de polynômes. C'était un cours où a priori c'était du Maple qu'il fallait faire, mais j'ai demandé si je pouvais faire du Sage, et on m'a dit que pourquoi pas, du coup j'ai découvert python et Sage à ce moment, et je me suis débrouillé vite fait en lisant la doc et un livre libre en français sur Sage. Pour ce cas d'utilisation précis, c'était moins embrouillant que Maple, j'ai eu l'impression, car les structures sont de vrais objets, c'est un peu plus typé, en quelque sorte. D'un autre côté, j'ai remarqué qu'une fonction (calcul d'une base de gröbner) était moins bonne, et pour des manipulations purement symboliques d'expressions, Sage me semble moins bon aussi (il utilise Maxima derrière, il me semble). Mais bref, j'ai pas l'impression d'avoir eu plus de problèmes que ceux qui faisaient du Maple alors qu'ils utilisaient ce logiciel depuis des années.
En fait, le truc le plus dur avec Sage, c'est peut-être réussir à l'installer, à cause des dépendances un peu beaucoup nombreuses.
[^] # Re: Logiciels libres
Posté par InsideLoop . Évalué à 2.
OCaml a pour moi plusieurs défauts comme premier langage :
- Il met en avant la programmation fonctionnelle alors que l'essentiel des langages fonctionne de manière impérative. Du coup, les élèves sortent de prépa en ayant le reflex de la récursivité pour presque tous les problèmes. Pour exploser la pile, il n'y a pas mieux ;-)
- Il n'y a quasiment aucune bibliothèque. Si vous voulez charger une image, résoudre numériquement un système linéaire ou télécharger un fichier sur internet, vous êtes rapidement tout nu. Du coup, l'informatique reste une discipline qui a du mal à se mélanger aux autres disciplines comme la physique. On fait de l'info pour faire de l'info.
Bref, OCaml est un excellent langage pour préparer les élèves à faire de la recherche en informatique. C'est à mon avis un très mauvais langage pour la grande majorité des élèves qui utiliseront plus tard l'informatique comme un outil.
En informatique pour tous, depuis la reforme de 2013, tout se fait en Python, sauf une petite partie du programme qui peut se faire en Python ou en Scilab. Quel intérêt ? Cela rend la conception de sujets plus difficiles et la correction encore plus. C'était déjà la cas avant où OCaml et Pascal étaient autorisés pour l'enseignement et cela posait pas mal de problèmes pour des questions qui étaient simples dans un langage et très difficiles dans un autre. C'est pourquoi je disais que c'était un choix à mon avis irresponsable. Sinon, n'oubliez pas que l'éducation nationale ne forme aucun prof d'informatique (pas d'agreg d'informatique par exemple) et que ce sont les profs de maths qui le plus souvent enseignent l'informatique. C'est la raison pour laquelle l'informatique en prépa est souvent réduite à des choses assez "mathématiques" comme l'algorithmique pure ou les langages reconnaissables.
Enfin, pour ce qui est des logiciels de calcul formel, bien entendu que n'importe quel logiciel libre peut faire ce que l'on demande aux étudiants. Il y a même des domaines très spécifiques comme la théorie des groupes dans lesquels les logiciels libres sont bien plus puissants que Mathematica ou Maple. Seulement, ces logiciels ayant un nombre très avancé de fonctions, sans documentation de qualité, il est souvent impossible de s'y retrouver. Enfin, je crois qu'il est essentiel d'apprendre des logiciels qu'ils utiliseront dans leur vie professionnelle. C'est pourquoi passer du temps sur XCas est ridicule. Malheureusement, il n'y a aucun logiciel de calcul formel libre complet et bien documenté. Sage a eu un certain succès, mais c'est juste une grosse usine à gaz qui essaie de faire tenir ensemble un tas de logiciels qui n'ont jamais été écrits pour fonctionner ensemble. J'ai peu d'espoir sur un logiciel de calcul formel libre à court terme. Il était question à un moment que MuPAD devienne libre. C'était un superbe logiciel, bien documenté, mais il a fini dans les mains de Mathworks ;-(
[^] # Re: Logiciels libres
Posté par anaseto (site web personnel) . Évalué à 7.
Je suis d'accord qu'OCaml ne sera pas le langage qu'ils utiliseront ensuite pour la plupart, et pour de bonnes raisons pratiques. Mais pour moi ce n'est pas une raison pour que son apprentissage n'ait pas d'intérêt pour enseigner quelque chose de spécifique (comme certains algos). Ce que je veux dire, c'est qu'un langage, c'est un outil, et qu'il faut essayer d'en choisir un adapté à chaque problème et que, si plus tard ils choisiront un langage pour telle bibliothèque, parce que ça leur simplifiera la vie, en attendant, il me semble intéressant d'habituer les élèves à plusieurs langages pour leur faire sentir que tous n'ont pas les mêmes objectifs, qu'ils voient d'eux-mêmes qu'OCaml pour faire du traitement de texte et des petits scripts, c'est pas idéal, mais Python pour des algos qui manipulent des structures de données complexes non plus. Même si apprendre un peu d'OCaml leur reste un peu comme de la culture générale, je pense qu'il reste toujours quelque chose d'utile et que viser, dès le(s) premier(s) langages, à présenter uniquement ce que la majorité utilisera le plus probablement, risque à mon avis leur donner une vue très restreinte, et leur priver de comprendre que chaque langage existe normalement pour répondre à un problème, c'est juste qu'il y a beaucoup de problèmes différents.
C'est vrai, mais, en même temps, c'est pas une mauvaise idée d'un point de vu pragmatique, je trouve, car tout refaire de zéro me semble difficile. Et même si le résultat aura peut-être du mal à être parfait à court terme, j'ai eu l'impression que c'était utilisable pour beaucoup de choses.
[^] # Re: Logiciels libres
Posté par Francky (site web personnel) . Évalué à 2.
En ce qui me concerne, je ne vois que des avantages à inciter les plus jeunes (les bons collégiens néophytes) à coder en Python.
Sur FranceIOI ils trouvent de bons exercices pour commencer.
Python permet se s'exprimer parfois de façon assez matheuse, parfois de façon de très classique (impérative).
La documentation est abondante, les bibliothèques très vastes, bref parfait langage pour débuter àmha.
Pour les matheux, au lycée, une initiation à Sage semble être la continuité logique. Je ne trouve pas que l'utilisation typique au lycée soit complexe. Après oui, il reste à faire une belle documentation pédagogique sur son utilisation. Aux claviers, libriens!
Pour les non matheux, proposer des activités en Python me semble pertinent. Les artistes, les bidouilleurs du futur ne sont-ils pas tenter de faire de petits scripts pour ajouter telle ou telle fonction à Gimp ou autre logiciel. Ce sont des compétences qu'il faudrait enseigner à un public plus large.
Ensuite, comme tout le monde, chacun choisit le langage le plus adapté à ses besoins, … de façon libre.
==
Au passage un grand merci pour cette clé USB agreg, et les conditions dans lesquelles se passent l'oral. J'ai apprécié.
[^] # Re: Logiciels libres
Posté par InsideLoop . Évalué à 1.
Écrire un logiciel comme Maple/Mathematica qui fait à la fois du calcul formel et du numérique est un travail titanesque. Je pense qu'un tel projet nécessiterai plus d'efforts que d'écrire une suite de compilateurs comme gcc ou llvm/clang. C'est pour cela qu'il y a peu de chances qu'un projet libre rivalisant avec Maple/Mathematica fonctionne. C'est dommage, mais j'ai laissé tombé les logiciels libres dans ce domaine.
[^] # Re: Logiciels libres
Posté par anaseto (site web personnel) . Évalué à 3.
D'un point de vue logistique, c'est en effet pas idéal. Mais de mon point de vue le problème est plus d'autoriser deux langages pour faire la même chose, du coup deux fois le même sujet. Ça n'empêche par contre pas d'utiliser deux langages si c'est pour des problèmes différents, du moment que pour chaque problème, il n'y en a qu'un.
[^] # Re: Logiciels libres
Posté par InsideLoop . Évalué à 1. Dernière modification le 09 avril 2015 à 21:27.
Le problème est que certains élèves auront fait du Python et d'autres (j'espère peu) auront fait du Scilab. Il passeront la même épreuve écrite et ayant été jury de concours, je sais très bien comment cela va se passer : les épreuves seront écrites pour le Python et au dernier moment on ajoutera une version de la question en Scilab. Les correcteurs connaitront le Python et auront une très vague idée de Scilab (je sais, ils devraient savoir programmer très bien dans les deux, mais en pratique je vous assure que cela ne sera pas le cas). Au final les élèves faisant du Scilab seront désavantagés.
Le problème s'est posé pendant 20 ans avec les épreuves faites pour OCaml/Pascal. Il continuera donc surement avec Python/Scilab.
[^] # Re: Logiciels libres
Posté par lasher . Évalué à 3.
Un excellent bouquin "pratique" à propos d'OCaml: http://shop.oreilly.com/product/0636920024743.do
… et écrit par un mec qui bosse pour le côté obscur (Jane Street, une boite qui fait du trading à haute fréquence). Il a une présentation/introduction très cool sur InfoQ.Il y explique entre autres que OCaml souffr(e|ait) d'un manque de bibliothèques standard « utiles », et que c'est justement ce que ce mec et ses collègues se sont employés à changer.
D'autres boites qui utilisent OCaml: https://ocaml.org/learn/companies.html
Si on élargit « OCaml » à ses dérivés, on pourrait potentiellement rajouter F#.
[^] # Re: Logiciels libres
Posté par InsideLoop . Évalué à 2.
Je veux bien considerer F# et OCaml comme "le même" langage. Mais cela reste des langage de niche.
Il est probable que D ou Rust aient déjà plus d'utilisateurs. Si on regarde Facebook par exemple, je crois qu'ils investissent dans le D.
[^] # Re: Logiciels libres
Posté par lasher . Évalué à 3.
Je sais que c'est juste une supposition, mais je demande quand même des preuves. J'ai pas mal entendu parler de boites qui utilisent des langages fonctionnels (OCaml, Scala, F#) pour faire du HFT. J'ai aussi connaissance de certaines boites qui utilisent OCaml pour faire des simulations sur des modèles d'interactions moléculaires. Je n'ai (pour le moment) entendu personne me dire qu'ils utilisent D ou Rust en production pour leur pile logicielle (même partiellement).
[^] # Re: Logiciels libres
Posté par InsideLoop . Évalué à 0.
Comme ma société fait de l'optimisation de code scientifique, je me suis pas mal intéressé au monde de la finance et en pratique la majorité de leurs codes sont soit en C++ soit en C#. Mais c'est vrai que l'on trouve une partie des utilisateurs de languages fonctionnels (Ocaml, F#, Mathematica) dans la finance.
Pour le D, Facebook l'utilise http://www.drdobbs.com/mobile/facebook-adopts-d-language/240162694 . Ils ont même embauché Andrei Alexandrescu, l'inventeur du D. Donc c'est assez sérieux pour eux.
Pour Rust, leur site conseille de ne pas l'utiliser en production. C'est donc trop jeune.
De son côté OCaml a 20 ans. Et même si il a un succès relatif, c'est resté un langage de niche.
[^] # Re: Logiciels libres
Posté par lasher . Évalué à 5.
Arguer que parce qu'il a 20 ans, OCaml a raté le coche, je pense que c'est s'avancer un peu vite.
Pendant des années, on a considéré les langages fonctionnels comme élégants mais pas adaptés à un environnement de production. Depuis ~10 ans, on voit pulluler les « extensions fonctionnelles » aux langages OO (Java et C++ entre autres), et on s'entend rappeler que pas mal de langages de haut niveau (de type Perl) ont presque toujours eu une partie des constructions habituellement attribuées aux langages fonctionnels.
Mais depuis que les architectures multicœur sont arrivées, tout à coup, les langages fonctionnels, et en particulier les langages fortement typés reviennent à la mode. Entre autres, Scala est sans doute le plus populaire (pour le big data on a SPARK qui l'utilise, et sinon Twitter est bien connu dans le genre). Scala est pour moi un langage « multi-paradigme » qui fonctionne et est relativement populaire car (tout comme F# avec .Net) il s'appuie sur les bibliothèques standard (et moins standard) de Java, tout en proposant une syntaxe principalement fonctionnelle (et qui je trouve est quand même proche de celle de OCaml par bien des aspects).
OCaml a réellement souffert du manque de bibliothèques utiles pour permettre autre chose que des machins académiques. Mais tout comme les langages fonctionnels ont été proposés il y a plus de 50 ans et n'ont commencé à percer qu'il y a 5-10 ans pour des choses plus « grand public », il n'est pas complètement improbable que OCaml trouve un public plus large à mesure que sa bibliothèque « standard » s'agrandit.
J'aime bien Scala, mais on paie le prix qu'on paie aussi avec Clojure et … Java : on paie le prix de la JVM qui est lente à charger, et RAMophage. De plus, bien que le typage soit fort en Java/Scala/blah, il reste dynamique, ce qui pour des applis haute-performance est assez gênant. Par exemple, avec SPARK ça va car on part de loin : Hadoop fait bien trop de copies des données intermédiaires sur HDFS, et du coup SPARK semble 1000 fois plus rapide en comparaison simplement parce qu'il cherche à garder les données le plus possible en mémoire. De plus, on pense généralement au big data en termes de quantité de données avec un traitement simple dessus : on paie plus le prix des communications qu'autre chose.
Les gros labos de recherche (DOE/DOD aux USA, CEA, INRIA, etc., en France) commencent à sérieusement se pencher sur le « big compute » qui rajoute de gros traitements par-dessus des environnements « big data », et là je pense qu'on va commencer à voir fleurir des solutions à base de langages avec un typage statique, et en règle générale une capacité d'exploiter le matériel de façon plus efficace. Ça veut très certainement dire que pour les couches les plus basses on va se servir de C/C++, mais je n'exclus pas la possibilité d'utiliser un langage de type OCaml, surtout si les utilisateurs ont déjà pris l'habitude d'utiliser Scala…
[^] # Re: Logiciels libres
Posté par InsideLoop . Évalué à 1. Dernière modification le 10 avril 2015 à 08:21.
Merci lasher pour ton intervention. J'avais lu avec interêt ton article "Ou vont les supercalculateurs ?". Si ce n'est pas indiscret, pour qui travailles-tu ?
Concernant les langages et le calcul parallèle, je comprends bien l'avantage des types non mutables pour éviter les "data race" et donc l'avantage des langages fonctionnels. Cependant, si on a besoin de parallélisme, on est bien souvent amené à utiliser OpenMP, MPI voire CUDA. On se retrouve donc contraint à développer en Fortran ou C/C++ si on veut gérer finement tout cela. Je n'ai jamais vu un bouquin sur le HPC qui utilise autre chose que du C/C++ (ou du Fortran). Dans ces applications il est d'ailleurs hors de question d'utiliser une JVM.
Du coup, les langages fonctionnels pour le HPC, j'en entends souvent parler, mais je ne les vois jamais. Est-ce que c'est une réalité aujourd'hui où une direction que les universitaires (qui n'ont pas autant de contrainte historique que beaucoup d'industriels et qui ont dans leur rang beaucoup plus d'experts en langage fonctionnel) souhaitent prendre ?
[^] # Re: Logiciels libres
Posté par grim7reaper . Évalué à 1.
Pour Haskell, il y a des bibliothèques comme Repa ou Accelerate.
[^] # Re: Logiciels libres
Posté par InsideLoop . Évalué à 1. Dernière modification le 11 avril 2015 à 08:38.
Le seul succès d'un langage fonctionnel que je connais en HPC, c'est la bibliothèque FFTW. C'est une excellente bibliothèque pour calculer des transformées de Fourier rapide. Ils ont utilisé OCaml non pas pour la bibliothèque mais pour générer du code C qui constitue la bibliothèque.
Allez voir http://benchmarksgame.alioth.debian.org qui est a ma connaissance la meilleure comparaison de performance entre les implémentations des différents langages (cela a bien sur des défauts, mais c'est difficile de faire mieux). Le Haskell et l'Ocaml se prennent un facteur 2 en moyenne face au C/C++/Fortran.
Si certains qui font du High Frequency Trading utilisent des langages fonctionnels, c'est qu'ils font souvent du code "jetable". Le code doit être : rapide, correct et développé rapidement. C'est la partie "correct" et "développé rapidement" qui les poussent vers les langages fonctionnels, pas la rapidité. Bien sur si ils se prenaient un facteur 100 par rapport au C, cela leur poserait problème, mais ils sont prêt à se prendre un facteur 2.
Les langages fonctionnels seront plus rapide que le C/C++/Fortran le jour où les compilateurs auront une vision globale du code meilleure qu'un bon programmeur. Autant, sur une vision locale, les compilateurs sont bien meilleurs que n'importe quel humain, sur une vision globale, ils sont complètement myopes.
[^] # Re: Logiciels libres
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
La FFTW est géniale mais va l'utiliser sur 10_000 coeurs ;-) La version MPI a encore des sacrés progrès à faire et il faut surtout qu'un mathématicien trouve trouve une méthode géniale pour paralléliser la FFT sur un cluster ! Nvidia et Intel cherche aussi (Nvidia en a vraiment besoin pour ses GPU, idem pour Intel avec les Xeon Phi) mais pour le moment, je n'ai rien vu de génial.
Les compilateurs ont déjà une vision globale, par exemple l'option -ipo de ifort.
IL n'y a pas qu'un problème de compilateur, si tu fais du HPC sur un très grand nombre de cœur, tu mappes ta structure de données sur des tableaux. C'est une des raisons pour lesquelles il faut souvent écrire les codes spécifiquement pour le HPC. Via le bus InfiniBand, tu attaques via ton code hybride MPI/OpenMP tout en adresse (Fortran). Tu minimises toutes les copies. C'est une manière de programmer très différentes d'Erlang qui fait tout l'inverse par exemple ;-)
J'aimerais bien qu'un code Erlang soit plus performant qu'un code Fortran mais en on n'en est pas encore là. Par contre, il est tout à fait possible qu'à moyen terme, du code Erlang (ou équivalent) soit plus facile à concevoir et à maintenir et soit suffisamment performant pour qu'on s'en satisfasse sur les gros clusters HPC ;-)
[^] # Re: Logiciels libres
Posté par InsideLoop . Évalué à 1.
J'ait fait du Fortran orienté objet pendant 3 ans et sur un code de 15 000 lignes j'ai compris ma douleur avec -ipo. J'avais des classes avec des getter qu'il fallait absolument inliner pour la performance, d'où l'utilisation de -ipo. Malheureusement, avec ce code qui restait de taille raisonnable, la passe -ipo prenait parfois 20 minutes :-(. Donc, -ipo est à utiliser avec parcimonie.
Quand je parlais de vision globale, j'imaginais un compilateur capable de transformer automatiquement des arrays of struct en struct of arrays ou des optimisations qui nécessitent un peu de recul. C'est la que les compilateurs n'ont quasiment aucune compétence.
Je fais du conseil en HPC et des gens qui utilisent 10 000 coeurs, je n'en vois pas tous les jours. On les voit bien sur dans les plaquettes publicitaires, au CEA ou dans certaines universités mais il la plupart des codes scientifiques tournent sur des bonnes workstation (genre bi-Xeon) voire souvent des portables ;-)
Au passage, si vous voulez vraiment savoir ce que les gens utilisent en HPC, vous pouvez lire ceci : http://www.amazon.fr/High-Performance-Parallelism-Pearls-Programming-ebook/dp/B00PLOC4D6/ref=sr_1_cc_1?s=aps&ie=UTF8&qid=1428767960&sr=1-1-catcorr&keywords=parallel+pearls . On y voit du Fortran, C++ (qui ressemble surtout à du C, sans std::vector par exemple), OpenMP, MPI.
[^] # Re: Logiciels libres
Posté par lasher . Évalué à 3.
L'option d'inlining inter-procédural est à utiliser quand tu es certain que ton code est correct, et qu'il est déjà bien optimisé avec
-O3. Une fois que tu as cette garantie, alors ça vaut le coup d'utiliser-ipo, car a priori tu ne l'utiliseras qu'à la toute fin, quand tu es (quasi-)certain que tu ne vas pas retoucher au code de sitôt.Après, tu peux toujours spécialiser le code via
-pgo(profile guided optimization), qui permet de filer un jeu d'entrée représentatif pour ton programme et qui permet àiccd'optimiser les branchements en fonction de ce que tu lui donnes. Évidemment, si le jeu d'entrée varie énormément en production, cette option n'est pas très utile…[^] # Re: Logiciels libres
Posté par lasher . Évalué à 2.
Euh, tu es sûr pour OCaml? Dans mes souvenirs, Matteo Frigo avait utilisé Cilk pour écrire FFTW…
Mmmh. Self-EDIT: après avoir parcouru le papier sur FFTW, il semblerait que j'ai eu tort, et il utilisait OCaml 2.0 ou 2.1…
[^] # Re: Logiciels libres
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Je rappelle pour ceux qui l'aurait oublié que le Fortran est un langage objet gérant l'héritage simple.
[^] # Re: Logiciels libres
Posté par InsideLoop . Évalué à 0. Dernière modification le 11 avril 2015 à 18:12.
Je sais bien. Il faut quand même savoir que c'est très récent car même si cela date du Fortran 2003, ce n'est utilisable que depuis environ 2010. Vu le nombre de bugs que j'ai remonté chez Intel et ifort, je ne suis pas sur que beaucoup de personnes l'utilisent. Le code Fortran 2003 de ce bouquin http://www.amazon.fr/Scientific-Software-Design-Object-Oriented-Way/dp/1107415330/ref=sr_1_1?ie=UTF8&qid=1428768323&sr=8-1&keywords=scientific+object+oriented+way ne compilait avec quasiment aucun compilateur il y a 2 ans.
Je continue à penser que le Fortran est un excellent langage pour développer des codes scientifiques. Mais je suis passé au C++ pour mes nouveaux projets car : il y a un type entier non signé sur 8 bits (essentiel pour l'image),cela se vend mieux, il y a de très bonnes IDE (CLion de jetbrains), de bonnes bibliothèques de tests unitaires, compile sur tout ce qu'on veut (pas de compilateur Fortran sur les téléphones par exemple) et le langage est très sur si on ne fait aucun "new/delete", ce qui est possible aujourd'hui.
[^] # Re: Logiciels libres
Posté par grim7reaper . Évalué à 1.
Et pourtant, c’est possible
[^] # Re: Logiciels libres
Posté par InsideLoop . Évalué à 2. Dernière modification le 11 avril 2015 à 21:46.
J'avais vu cela, ce qui prouve que c'est possible sous Android. Sous iOS, je crois que c'est impossible. Le C++ sans aucune bibliothèque (surtout pas Boost) reste très portable et compile de facto sur plus de plateformes que le Fortran. Et puis, en un an de C++ je n'ai quasiment reporté aucun bug de compilateur chez Intel (sauf quelques optimisations qui n'étaient pas faites). Avec ifort, j'ai bien renvoyé une dizaine de bugs chez Intel en 3 ans. C'était des bugs qui concernaient le Fortran 2003, mais certains étaient vraiment génants.
En fait, le truc qui me manquerait le plus en revenant au Fortran, ce serait :
- Un bon IDE (Visual Studio avec le plugin Intel et Eclipse + Phortran ne sont pas à la hauteur des outils Jetbrains)
- Google Test
Bref, c'est l'ensemble des outils à côté du langage qui me manqueraient. En même temps, quitter le C++, ce serait
- se débarrasser des rigolos qui font du template metaprogramming
- se débarasser des rigolos qui font des trucs illisibles pour se donner l'air intelligent
- se débarasser des gens qui font std::vector< std::vector< double > > pour faire une matrice (Ahrrrrrrr) et de tous ceux qui ne s'intéressent pas à la mémoire en général
- se débarrasser des problèmes d'aliasing
[^] # Re: Logiciels libres
Posté par grim7reaper . Évalué à 2.
Parce que l’environnement est très fermé. Sans cela, je pense que c’est possible.
Ouais, c’est un fait que les compilateurs Fortran soient plus bogués que les compilateurs C (et C++), et surtout sur les derniers standards (quand le support dudit standard est utilisable). Le fait qu’il y ai moins d’utilisateurs y est pour quelque chose.
Mais le Fortran a de vrais avantages par rapport au C++ pour ce qui est calcul numérique (pas d’aliasing, comme tu le dit, de vrai tableaux, la notion de parallélisation intégrée au langages, …).
Mais oui, les outils autour sont parfois limité (y’a bien quelques bibliothèques de tests unitaires, Doxygen pour la doc (pour les IDE, je n’utilise pas ce genre d’outil donc ça ne me manque pas), …).
[^] # Re: Logiciels libres
Posté par InsideLoop . Évalué à 1.
Bref, ça commence à sentir le roussi pour le Fortran. C'est dommage car c'est un excellent langage, mais j'ai l'impression que les temps sont durs pour les langages non généralistes.
[^] # Re: Logiciels libres
Posté par grim7reaper . Évalué à 1.
Oui, restrict existe en C et C++, mais comme tu le dis toi-même les compilateurs n’en font pas un usage optimal (sûrement parce que des gens l’utilise sans comprendre et que ça casserait leur code (ce qui ne serait pas un mal, soit dit en passant)).
Pour les CoArray, ça semble en effet loin d’être mature (pour ce que j’en lit sur comp.lang.fortran), ce qui est dommage car prometteur (sur le papier).
Il me semble que CUDA et OpenCL sont utilisable en Fortran aussi (aucune idée de ce que valent les outils, je n’y ai pas touché), cela dit c’est un problème moindre car tout les problèmes ne se prêtent pas au calcul sur GPU (mais ça reste un manque pour un langage dont le domaine principal est le HPC).
[^] # Re: Logiciels libres
Posté par lasher . Évalué à 2.
À noter que les gens de l'université de Houston (USA) ont récemment implémenté (en libre) une version complète de la dernière norme de Fortran, y compris les CoArray, etc.
[^] # Re: Logiciels libres
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
Je ne serais pas aussi dur. Cela fait des années et des années que 99% des personnes pensent que le Fortran est mort et il est toujours la. Il a fortement évolué, bien plus de le C par exemple… Il y a 15 ans, c'était impossible de faire du Fortran sans avoir un compilateur privateur, de nos jours, gfortran s'en sors pas si mal sur de nombreux code (même si le résultat n'est pas aussi rapide qu'avec ifort). Pour les Coarrays, cela avance via OpenCoarray (http://opencoarrays.org/) mais il faut bien voir que l'objectif est d'avoir une manière simple de faire du parallèle intégré dans le langage donc on ne sera pas plus rapide qu'un code hybride aux petits oignons OpenMP/MPI… Il n'y a pas de magie derrière les Coarray ;-)
De notre coté, on utilise de plus en plus hdf5 et netcdf4 parallel (MPI). Il y a des gains énorme à basculer la dessus pour les entrées sorties.
[^] # Re: Logiciels libres
Posté par lasher . Évalué à 4.
Salut, merci d'avoir lu l'article (qui promettait une suite pour « bientôt », et qui n'est jamais venue… Je suis en train d'y travailler — si si).
Je bosse dans une fac US. Les gens avec qui nous bossons varient : mon labo a aidé (bien avant que je les rejoigne) à la création de systèmes « manycore » à une époque où le multicœur n'était pas encore sur le point d'arriver sur le marché. Nous bossons sur tous les aspects « logiciel système » pour les architectures manycore à destination du calcul haute-performance: multithreading, gestion à grain fin des ressources systèmes, etc.
Concernant les langages utilisés en HPC: oui, la grande majorité des codes reste écrite en C ou Fortran (et parfois C++). Et oui, les gens utilisent en général un mix entre MPI (qui représente ~80% à 90% des codes qui tournent sur des grappes de calcul et supercalculateurs), OpenMP (pour le parallélisme intra-nœud, et qui représente peut-être 10% supplémentaires), et le reste (CUDA, OpenCL, OpenACC, etc.) se dispute les miettes. Cependant, avec l’avènement du « data science » (qui est lui-même une continuation des environnements « big data »), et plus précisément avec SPARK, on commence à voir venir les langages fonctionnels comme d'excellents langages de type « DSL » (domain-specific language). C'est d'ailleurs là où je trouve qu'ils excellent : on crée un sous-ensemble de langages de programmations pour un domaine scientifique donné, ce qui est relativement simple si on utilise des constructions fonctionnelles avec du « pattern matching ». (Common) LISP a longtemps été considéré comme le champion dans le genre.
On n'en est pas là cependant. Pour le moment, les langages façon C restent les plus utilisés, avec pas mal de scientifiques qui utilisent de plus en plus les environnements à base de Python (et qui utilisent des bibliothèques optimisées en C). Matlab est aussi pas mal utilisé dans ce contexte, et lui aussi utilise des bibliothèques optimisées, par exemple ATLAS pour l'algèbre linéaire, ou bien CuBLAS lorsqu'un GPU Nvidia est disponible, etc.
Il faut aussi mentionner OpenMP 4.x, qui tente de proposer 1000 constructions pour pouvoir tirer avantage des accélérateurs (Xeon Phi, GPU, etc.), grouper des threads ensemble, tirer partie des instructions SIMD (SSE, AVX, Altivec, etc.), étendre les possibilités de multithreading, etc. Malgré tout, ça ne reste « qu'une » extension à C/C++/Fortran.
Bref, l'utilisation de langages autres que C/C++/Fortran (avec parfois du Python en « front-end ») reste anecdotique ou cantonnée à une niche.
Il existe une famille de langages qui tente de proposer une façon d'exprimer le parallélisme pour des supercalculateurs tout en augmentant la productivité du programmeur. On les appelle langages PGAS (Partitioned Global Address Space). Les plus connus sont UPC (Universal Parallel C), X10 (proposé par IBM), et Chapel (proposé par Cray). Il y en a d'autres, cf. mon lien. La plupart proposent une implémentation de référence libre, mais malheureusement, les performances restent loin d'être au rendez-vous. Cependant, c'est normal : il est déjà difficile de correctement optimiser du code séquentiel en utilisant les graphes de flot de contrôle et de flot de données (ou de dépendance de données), alors je te laisse imaginer ce qui se passe lorsqu'en plus on doit gérer du code parallèle (même si c'est exprimé plus ou moins explicitement). Malgré tout, même si ce sont des langages « usine à gaz », je pense qu'ils représentent une bonne avancée dans le domaine, et on peut espérer qu'ils vont au moins fournir une base d'inspiration pour des langages explicitement parallèles plus « légers » — C'est déjà le cas avec X10 : le langage Habanero Java est un X10-light qui ne reprend que les mécanismes jugés vraiment intéressants (il existe un langage Habanero C, qui comme son nom l'indique repose sur un « back-end » écrit en C, mais il est par beaucoup d'aspects bien plus expérimental).
Enfin, j'aimerais mentionner Cilk/Cilk++/CilkPlus, pour plusieurs raisons:
Je pense en particulier à OpenMP 4, qui ajoute plein de fonctionnalités — tellement que contrairement aux versions précédentes du standard, il n'y a pas d'exemples de code… et malgré tout, le standard a plus que doublé en taille par rapport à la v3. ↩
[^] # Re: Logiciels libres
Posté par InsideLoop . Évalué à 0. Dernière modification le 13 avril 2015 à 20:35.
LISP, Cilk, IA, … Tu bosses au MIT ?
Sinon, tu as déjà utilisé Julia ? Qu'en penses-tu ?
[^] # Re: Logiciels libres
Posté par lasher . Évalué à 2.
Non, mais mon patron a été étudiant là-bas. ;-) Il a aussi créé un concurrent à Cilk dans les années 90, du coup je connais plutôt très bien l'environnement (mes connaissances concernant LISP sont justes de la « culture générale »).
J'ai oublié de préciser un dernier truc pour Cilk (CilkPlus en fait) : depuis la version 4.8 ou 4.9, gcc le supporte partiellement (et depuis la version 5.0, complètement). Ça en fait un langage facile à tester.
Je n'ai pas d'avis sur Julia (jamais regardé de près, et encore moins utilisé).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.