Les deux plus grosses en fait (PS4, XBox One). C'est en fait très logique pour des consoles de jeu : avec les APU, on a de la mémoire partagée entre le GPU et le CPU, et tout est on-package/on-chip. Forcément, comme le matériel est fixe, ça veut dire qu'on peut produire des bibliothèques d'utilitaires pour les dévs de jeux qui tirent correctement parti de ce genre de technologie. C'est plus compliqué et moins évident pour ceux qui font de la programmation plus « générique ».
Il y a aussi eu l'i860, qui était un « vrai » processeur RISC produit par Intel au milieu des années 90. Par contre je ne sais pas s'ils avaient décidé de produire ce processeur juste pour le calcul haute performance, ou bien s'ils avaient des ambitions plus larges.
Des clusters d'Opteron c'était très très très courant a la fin des années 2000.
C'était le moment ou leur rapport perf / prix étaient très bon comparé a de l'IA qui n'a jamais décollé et des xeons qui étaient plus cher pour pas mieux.
Surtout, les Opterons avaient l'HyperTransport, alors qu'Intel n'avait toujours pas produit de processeurs (IA64 ou x86) avec un réseau d'interconnexion efficace. Pour le cluster du CEA (à base d'IA64), Bull avait conçu et produit l'interconnect pour pouvoir faire communiquer 4 Itanium2 sur un même nœud à mémoire partagée.
C'est une question très pertinente. Je pense que les architectures ARM sont suffisamment utilisées par des hackers pour que GCC ait un niveau d'optimisation raisonnable (sans parler du fait qu'une grande partie des transformations sont opérées dans le middle-end, qui se fout de l'archi cible). Par contre, pour le POWER8, si on n'utilise pas le compilo d'IBM, je ne sais pas à quel point GCC sait optimiser spécifiquement pour ce processeur (je suppose quand même que le « sous » jeu d'instruction PowerPC est correctement compris par gcc).
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é).
À 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.
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.
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 à icc d'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…
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.
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…
Tout dépend de ce qui est demandé de faire en maths. À moins de demander d'analyser une fonction de type la plupart du temps, on demande aux élèves de calculer des trucs un chouïa plus compliquées. La calculatrice est là principalement pour aider l'élève à vérifier qu'il ne se goure pas.
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:
C'était l'un des rares environnements de programmation parallèle dans les années 90 (avec la v1 d'OpenMP, et un autre machin appelé EARTH);
dans les années 90, Cilk a permis de créer l'un des meilleurs programmes d'IA d'échecs pour machine parallèle;
Cilk (et ses successeurs) est à ma connaissance l'un des rares langages qui utilise un modèle d'exécution qui a des bornes prouvables pour l'ordonnancement des tâches, en temps et en espace;
enfin, c'est l'un des rares langages qui ne nécessite pas de connaître 10000 constructions parallèles pour créer du parallélisme1
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. ↩
Les prépas intégrées des INSA virent (ou ne gardent) qu'un certain pourcentage d'étudiants en fin de cycle. Les prépas des UT virent régulièrement les étudiants qui ne peuvent pas valider leurs 20 UV en 4 semestres (ou, si l'étudiant a une bonne excuse, 5 semestres). Enfin, je peux me tromper, mais au moins en maths, en licence (ou DEUG pour les plus vieux), l'utilisation de calculatrices est aussi interdite.
Concernant les prépas intégrées : elles sont certes beaucoup moins compétitives que les prépas classiques, mais restent malgré tout « élitistes ». Note que je n'ai pas de problème avec ça; il est même dommage que le choix phénoménal de pédagogies qui existe dans le supérieur (IUT/STS, premier cycle classique/prépa, école d'ingé/IUP/Master, etc.) n'existe pas dans le secondaire1. Cette diversité des enseignements qui mènent parfois au même diplôme (par ex: {prépa, IUT, licence} → {Master,diplôme d'ingé}), voire qui enseignent la même chose, au même niveau (je pense aux licences en fac vs. prépas) permet d'adapter la pédagogie à l'individu. Alors que dans le secondaire, pour un même programme, il n'existe qu'une forme unique d'évaluation (je ne sais pas si je suis clair).
On sort du sujet, mais si certes il existe des lycées pro, des lycées technologiques/techniques, et des lycées généralistes, le problème est qu'on attribue une hiérarchie implicite à ces derniers : généraliste > technologique > professionnel. Le problème est que même parmi les généralistes, il y a la hiérarchisation implicite S > SES > L. (ou bien E > C > D > B > A > F…). ↩
Quand à l’approche prendre sur internet, c’est quelque chose que je vois de plus en plus, notamment chez les plus jeunes, dans le monde professionnel. Et ce n’est pas toujours une réussite…
[note: « Quan*t* à … ! :-)]
J'ai eu une discussion avec un stagiaire il y a quelques années qui me demandait pourquoi je m'encombrais de bouquins (papier ou PDF) alors que toute l'info est sur le net la plupart du temps. Et je me suis évertué à lui expliquer qu'un bouquin a une structure, et que ça permet non seulement de comprendre l'aspect technique d'un langage, d'un soft, etc., mais aussi de comprendre comment appliquer une méthodologie au final. Il y a des articles sur le Web qui font ça très bien, mais de plus en plus de gens ont recours au « TL;DR. Je veux juste savoir quelle ligne mettre dans mon fichier de config. » Si c'est pour juste prototyper un truc, ça me semble une attente raisonnable. Mais si c'est pour le mettre en production, y'a intérêt à ce que l'utilisateur (du soft, de la fonction, etc.) pige correctement la philosophie derrière l'outil. Et très souvent, le zapping via tutoriels sur le net ne le permet pas.
Il n'y a qu'en France et en Argentine où on donne encore du crédit à ce genre de trucs. Même en Autriche (pays d'origine) ça a été remisé au placard.
J'aimerais avoir tes sources. Aux USA, la « psycho-analysis » reste très populaire. De plus, ce n'est pas parce que clairement Freud avait tort sur pas mal de point qu'il avait tort sur toute la ligne.
Pour ce qui est de l'enseignement de la psychanalyse en philo, je me souviens que nous avions étudié ce truc, et que le prof en avait profité pour faire un détour par la définition de la méthode scientifique de K.Popper, pour ensuite dire que selon cette définition, la psychanalyse, malgré la tonne de choses importantes qu'elle a apporté (que ça te plaise ou non, les notions de conscient/inconscient ou ça/moi/surmoi, si elles restent clairement perfectibles, représentent bien un modèle de la psyché humaine — et comme tout modèle, ça reste améliorable) n'est pas une méthode scientifique, puisque si le patient n'est pas d'accord avec le psychanalyste, ce dernier peut toujours dire que le patient fait un « rejet » (et donc, pas de falsifiabilité).
Bref. Au contraire, je trouve que parler de la psychanalyse en philo est excellent : on nous montre une méthode, on nous montre qu'elle semble avoir ouvert des portes, on nous explique que son créateur voulait en faire une science, puis on finit par expliquer que ce n'en est pas une, malgré les possibles ouvertures que cette méthode a engendrée. C'est un excellent cas d'étude.
Je ne me souviens pas si dans les annales du bac j'étais tombé sur un exercice comme ça (je sais qu'au bac lui-même ça ne m'était pas arrivé), mais très clairement en 1è/Tale, j'avais des exercices du genre « Analysez et tracez la fonction f sur l'intervalle [-20, +20] ». Et on attendait de nous:
Le tableau de signes (avec les notions de croissant, décroissant, etc.)
Les racines (à signaler graphiquement en plus de montrer les calculs)
Dire si la fonction était monotone ou pas, et s'il y avait un/des points d'inflexion — et le cas échéant de le(s) signaler graphiquement
Oui mais en prépa, on te … prépare à passer un concours difficile, et donc on te donne des problèmes à résoudre sans calculatrice, mais c'est aussi parce que c'est un moyen de filtrer lors des concours. Un ami m'a raconté que lorsqu'il était en début d'école d'ingé, lors d'un cours de mécanique, le prof demande aux élèves de calculer un truc quelconque (genre une équa diff, une intégrale, blah). Tout le monde en classe se met à gratter sévère. Le prof s'impatiente alors, et leur dit que c'est bon, ils ont tous passés un concours difficile, il sait qu'ils sont capables de résoudre ces problèmes à la main, mais là, ils sont en train d'apprendre à être ingénieurs, alors merci d'utiliser la calculatrice et de lui filer un résultat vite fait.
Pour valider des analyse comme le dis lasher, faut arrêter de déconner si on parle du bac :) La réponse tu l'as dans la question suivante !
Je ne me souviens franchement pas de ça. Je me souviens qu'on m'avait demandé de calculer les limites d'une fonction, ce qui signifiait trouver les racines, etc., et non, les questions d'après ne me donnaient pas la réponse.
Ben justement, on devrait. Je me souviens que pour le bac pendant des années (au moins toutes les années 90), on nous filait un formulaire pour l'épreuve maths, alors qu'en pratique, on utilise tout le temps ces formules, donc la plupart du temps on les connaît par cœur, mais en physique/chimie, alors que les formules étaient bien plus compliquées, on n'avait le droit à rien. Évidemment que j'ai fait comme tout le monde, et j'ai planqué mes formules pour la méca ou l'élec dans ma calculatrice. En plus, ayant fait tronc commun TI, j'avais besoin de me souvenir d'autres formules pour méca/élec qu'on ne voyait pas en physique (et là, merci à la HP48 qui avait toutes ces formules déjà codées en interne, avec de zoulis schémas électriques). Il était parfaitement possible de retrouver les formules en physique note bien, mais ça m'aurait fait perdre un temps fou.
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.
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…
Mouais, quand j'utilise une calculatrice graphique (ou un émulateur de calculatrice graphique), j'ai un ensemble de fonctions préchargées et qui couvrent 99% de mes besoins (quelques fonctions simples et utiles pour dériver/intégrer des fonctions, faire des calculs de probas simples, etc.). Lorsque je dois faire la même chose avec un soft sur un PC, soit c'est overkill (Matlab, Maple, Mathematica, MathCAD, Octave, R, etc.)1, soit en ligne uniquement et limité si on n'achète pas une licence (Wolfram Alpha), soit je dois tout faire, ou au moins trouver par moi-même les bons modules, espérer qu'il n'y a pas de bug pour les cas simples que je veux gérer, etc… Et malgré tout, je risque de devoir en partie programmer ce que je veux faire dans ce cas, même quand ça devrait être relativement simple.
En d'autres termes, si je dois faire des maths, même simples, mais au-delà de l'arithmétique de base (en libre), il faut que je passe par Sage (calcul symbolique), R (statistiques), Octave (par ex., algèbre linéaire, et autres bidules), GnuPlot (pour tracer les courbes), ou même LibreOffice Calc, etc. Et donc je dois avoir ça sur mon téléphone portable ? Ou bien au moins avoir une sorte d'interface graphique/web qui me permette d'interroger à distance un serveur qui aura tous ces outils (à ce train-là, autant utiliser Wolfram Alpha) ?
Ça me semble un peu lourd.
Note : il existe des applications non-libres pour Android (et je suis sûr pour iOS ou Win8 aussi) qui émulent des calculatrices graphiques.
Je précise : overkill car je ne fais pas de stats poussées (R), ou de maths poussées (Matlab/Octave), ou d'algèbre poussée (Maple/Mathematica). Par contre il m'arrive de me dire « tiens, il faudrait que je dérive/intègre ceci », ou « bon, il faudrait calculer la proba que ce truc arrive », etc. ↩
Et aussi, le fait qu'on puisse vérifier que l'analyse de fonction qu'on a faite est correcte en traçant la fonction sur la calculatrice fait gagner un temps fou. Pas besoin d'une TI-{92|89}/HP{48GX,49} pour le faire cependant : la plupart des calculatrices graphiques à moins de 40€ peuvent faire l'affaire.
Ça a déjà été dit par d'autres, et mieux que moi, mais le contexte du papier de Dijkstra, A Case Against the Go To statement, et que la plupart nomment "Go To Considered Harmful"1, n'est absolument pas contre l'utilisation du goto. Dans ce papier, Dijkstra est contre la programmation non-structurée, à une époque où les procédures et fonctions n'étaient pas toujours disponibles dans un langage de programmation, et où les structures de contrôle étaient parfois au mieux if/else.
Je recommande fortement la lecture (ou l'écoute) de ce monsieur, qui rappelle qu'après le papier de Dijkstra, Donald Knuth a écrit Structured Programming With go to Statements. Notamment, Knuth rapporte une conversation (informelle) avec Dijkstra à propos du goto:
I am not in fact disagreeing sharply with Dijkstra's ideas, since he recently wrote the following: "Please don't fall into the trap of believing that I am terribly dogmatical about [the go to statement]. I have the uncomfortable feeling that others are making a religion out of it, as if the conceptual problems of programming could be solved by a single trick, by a simple form of coding discipline!" 2
Si on traduit rapidement :
En réalité, je ne suis pas en désaccord avec les idées de Dijkstra, puisqu'il a récemment écrit ce qui suit : « S'il vous plaît, ne tombez pas dans le piège de croire que je suis extrêmement dogmatique à propos du goto. J'ai la désagréable impression que d'autres sont en train d'en faire une religion, comme si les problèmes conceptuels de programmation pouvaient être résolus par un simple artifice, sous la forme d'une simple discipline de codage ! »
May I ask if there is a reason why you prefer using goto instead of function recursion?
… qu'on pourrait traduire par
Puis-je demander s'il y a une raison pour laquelle vous préférez utiliser goto au lieu d'un appel récursif ?
L'auteur du code explique, benchmarks à l'appui, pourquoi dans ce cas précis, l'utilisation du goto est la meilleure solution, tout en conservant une lisibilité satisfaisante du code et en maximisant la performance en termes de bytecode généré et de temps d'exécution. Malgré tout, des gens lui ressortent le papier de Dijkstra sans avoir sans doute compris que la décision n'était pas prise sur un coup de tête, mais au contraire mûrement réfléchie après avoir analysé les autres solutions.
Bref. Lisez cet article, il est bon, il est intéressant, et il pointe vers tout plein de liens rigolos.
à cause de l'éditeur des « Communications of the ACM » qui avait reformulé le titre et soumis le papier au « courrier des lecteurs » pour que le papier court-circuite le processus de revue et soit publié plus vite. ↩
Hum. Ma première calculatrice graphique était une « petite » Casio qui avait coûté moins de 100FF (~15€) à mes parents. Elle était peut-être un peu juste pour le bac, mais je m'en suis servi en 2nde et première, et je n'ai eu une HP48 qu'en terminale (et d'occasion…).
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: Question arch x86
Posté par lasher . En réponse au journal Premières évaluations publiques d'un serveur non-IBM à base de Power8. Évalué à 2.
Les deux plus grosses en fait (PS4, XBox One). C'est en fait très logique pour des consoles de jeu : avec les APU, on a de la mémoire partagée entre le GPU et le CPU, et tout est on-package/on-chip. Forcément, comme le matériel est fixe, ça veut dire qu'on peut produire des bibliothèques d'utilitaires pour les dévs de jeux qui tirent correctement parti de ce genre de technologie. C'est plus compliqué et moins évident pour ceux qui font de la programmation plus « générique ».
[^] # Re: Question arch x86
Posté par lasher . En réponse au journal Premières évaluations publiques d'un serveur non-IBM à base de Power8. Évalué à 2.
Il y a aussi eu l'i860, qui était un « vrai » processeur RISC produit par Intel au milieu des années 90. Par contre je ne sais pas s'ils avaient décidé de produire ce processeur juste pour le calcul haute performance, ou bien s'ils avaient des ambitions plus larges.
[^] # Re: Question arch x86
Posté par lasher . En réponse au journal Premières évaluations publiques d'un serveur non-IBM à base de Power8. Évalué à 3.
Surtout, les Opterons avaient l'HyperTransport, alors qu'Intel n'avait toujours pas produit de processeurs (IA64 ou x86) avec un réseau d'interconnexion efficace. Pour le cluster du CEA (à base d'IA64), Bull avait conçu et produit l'interconnect pour pouvoir faire communiquer 4 Itanium2 sur un même nœud à mémoire partagée.
[^] # Re: Merci, et une question
Posté par lasher . En réponse au journal Premières évaluations publiques d'un serveur non-IBM à base de Power8. Évalué à 4.
C'est une question très pertinente. Je pense que les architectures ARM sont suffisamment utilisées par des hackers pour que GCC ait un niveau d'optimisation raisonnable (sans parler du fait qu'une grande partie des transformations sont opérées dans le middle-end, qui se fout de l'archi cible). Par contre, pour le POWER8, si on n'utilise pas le compilo d'IBM, je ne sais pas à quel point GCC sait optimiser spécifiquement pour ce processeur (je suppose quand même que le « sous » jeu d'instruction PowerPC est correctement compris par gcc).
[^] # Re: Merci, et une question
Posté par lasher . En réponse au journal Premières évaluations publiques d'un serveur non-IBM à base de Power8. Évalué à 3.
C'est mon problème avec ce benchmark:
Bref, j'aimerais avoir quelqu'un qui m'explique un peu comment lire les graphes.
[^] # Re: Logiciels libres
Posté par lasher . En réponse à la dépêche Agrégation et logiciels libres. É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é).
[^] # Re: Logiciels libres
Posté par lasher . En réponse à la dépêche Agrégation et logiciels libres. É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 lasher . En réponse à la dépêche Agrégation et logiciels libres. É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 . En réponse à la dépêche Agrégation et logiciels libres. É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: Què?
Posté par lasher . En réponse au journal Bac et calculatrices programmables : la fin ?. Évalué à 2.
Tout dépend de ce qui est demandé de faire en maths. À moins de demander d'analyser une fonction de type
la plupart du temps, on demande aux élèves de calculer des trucs un chouïa plus compliquées. La calculatrice est là principalement pour aider l'élève à vérifier qu'il ne se goure pas.
[^] # Re: Logiciels libres
Posté par lasher . En réponse à la dépêche Agrégation et logiciels libres. É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: Choquant !
Posté par lasher . En réponse au journal Bac et calculatrices programmables : la fin ?. Évalué à 2.
Les prépas intégrées des INSA virent (ou ne gardent) qu'un certain pourcentage d'étudiants en fin de cycle. Les prépas des UT virent régulièrement les étudiants qui ne peuvent pas valider leurs 20 UV en 4 semestres (ou, si l'étudiant a une bonne excuse, 5 semestres). Enfin, je peux me tromper, mais au moins en maths, en licence (ou DEUG pour les plus vieux), l'utilisation de calculatrices est aussi interdite.
Concernant les prépas intégrées : elles sont certes beaucoup moins compétitives que les prépas classiques, mais restent malgré tout « élitistes ». Note que je n'ai pas de problème avec ça; il est même dommage que le choix phénoménal de pédagogies qui existe dans le supérieur (IUT/STS, premier cycle classique/prépa, école d'ingé/IUP/Master, etc.) n'existe pas dans le secondaire1. Cette diversité des enseignements qui mènent parfois au même diplôme (par ex: {prépa, IUT, licence} → {Master,diplôme d'ingé}), voire qui enseignent la même chose, au même niveau (je pense aux licences en fac vs. prépas) permet d'adapter la pédagogie à l'individu. Alors que dans le secondaire, pour un même programme, il n'existe qu'une forme unique d'évaluation (je ne sais pas si je suis clair).
On sort du sujet, mais si certes il existe des lycées pro, des lycées technologiques/techniques, et des lycées généralistes, le problème est qu'on attribue une hiérarchie implicite à ces derniers : généraliste > technologique > professionnel. Le problème est que même parmi les généralistes, il y a la hiérarchisation implicite S > SES > L. (ou bien E > C > D > B > A > F…). ↩
[^] # Re: so 90's
Posté par lasher . En réponse au journal Bac et calculatrices programmables : la fin ?. Évalué à 8.
[note: « Quan*t* à … ! :-)]
J'ai eu une discussion avec un stagiaire il y a quelques années qui me demandait pourquoi je m'encombrais de bouquins (papier ou PDF) alors que toute l'info est sur le net la plupart du temps. Et je me suis évertué à lui expliquer qu'un bouquin a une structure, et que ça permet non seulement de comprendre l'aspect technique d'un langage, d'un soft, etc., mais aussi de comprendre comment appliquer une méthodologie au final. Il y a des articles sur le Web qui font ça très bien, mais de plus en plus de gens ont recours au « TL;DR. Je veux juste savoir quelle ligne mettre dans mon fichier de config. » Si c'est pour juste prototyper un truc, ça me semble une attente raisonnable. Mais si c'est pour le mettre en production, y'a intérêt à ce que l'utilisateur (du soft, de la fonction, etc.) pige correctement la philosophie derrière l'outil. Et très souvent, le zapping via tutoriels sur le net ne le permet pas.
[^] # Re: Ouais, ouais....
Posté par lasher . En réponse au journal Bac et calculatrices programmables : la fin ?. Évalué à 4.
J'aimerais avoir tes sources. Aux USA, la « psycho-analysis » reste très populaire. De plus, ce n'est pas parce que clairement Freud avait tort sur pas mal de point qu'il avait tort sur toute la ligne.
Pour ce qui est de l'enseignement de la psychanalyse en philo, je me souviens que nous avions étudié ce truc, et que le prof en avait profité pour faire un détour par la définition de la méthode scientifique de K.Popper, pour ensuite dire que selon cette définition, la psychanalyse, malgré la tonne de choses importantes qu'elle a apporté (que ça te plaise ou non, les notions de conscient/inconscient ou ça/moi/surmoi, si elles restent clairement perfectibles, représentent bien un modèle de la psyché humaine — et comme tout modèle, ça reste améliorable) n'est pas une méthode scientifique, puisque si le patient n'est pas d'accord avec le psychanalyste, ce dernier peut toujours dire que le patient fait un « rejet » (et donc, pas de falsifiabilité).
Bref. Au contraire, je trouve que parler de la psychanalyse en philo est excellent : on nous montre une méthode, on nous montre qu'elle semble avoir ouvert des portes, on nous explique que son créateur voulait en faire une science, puis on finit par expliquer que ce n'en est pas une, malgré les possibles ouvertures que cette méthode a engendrée. C'est un excellent cas d'étude.
[^] # Re: Choquant !
Posté par lasher . En réponse au journal Bac et calculatrices programmables : la fin ?. Évalué à 3.
Je ne me souviens pas si dans les annales du bac j'étais tombé sur un exercice comme ça (je sais qu'au bac lui-même ça ne m'était pas arrivé), mais très clairement en 1è/Tale, j'avais des exercices du genre « Analysez et tracez la fonction f sur l'intervalle [-20, +20] ». Et on attendait de nous:
[^] # Re: Choquant !
Posté par lasher . En réponse au journal Bac et calculatrices programmables : la fin ?. Évalué à 5.
Oui mais en prépa, on te … prépare à passer un concours difficile, et donc on te donne des problèmes à résoudre sans calculatrice, mais c'est aussi parce que c'est un moyen de filtrer lors des concours. Un ami m'a raconté que lorsqu'il était en début d'école d'ingé, lors d'un cours de mécanique, le prof demande aux élèves de calculer un truc quelconque (genre une équa diff, une intégrale, blah). Tout le monde en classe se met à gratter sévère. Le prof s'impatiente alors, et leur dit que c'est bon, ils ont tous passés un concours difficile, il sait qu'ils sont capables de résoudre ces problèmes à la main, mais là, ils sont en train d'apprendre à être ingénieurs, alors merci d'utiliser la calculatrice et de lui filer un résultat vite fait.
[^] # Re: Choquant !
Posté par lasher . En réponse au journal Bac et calculatrices programmables : la fin ?. Évalué à 2.
Je ne me souviens franchement pas de ça. Je me souviens qu'on m'avait demandé de calculer les limites d'une fonction, ce qui signifiait trouver les racines, etc., et non, les questions d'après ne me donnaient pas la réponse.
[^] # Re: Ouais, ouais....
Posté par lasher . En réponse au journal Bac et calculatrices programmables : la fin ?. Évalué à 2.
Ben justement, on devrait. Je me souviens que pour le bac pendant des années (au moins toutes les années 90), on nous filait un formulaire pour l'épreuve maths, alors qu'en pratique, on utilise tout le temps ces formules, donc la plupart du temps on les connaît par cœur, mais en physique/chimie, alors que les formules étaient bien plus compliquées, on n'avait le droit à rien. Évidemment que j'ai fait comme tout le monde, et j'ai planqué mes formules pour la méca ou l'élec dans ma calculatrice. En plus, ayant fait tronc commun TI, j'avais besoin de me souvenir d'autres formules pour méca/élec qu'on ne voyait pas en physique (et là, merci à la HP48 qui avait toutes ces formules déjà codées en interne, avec de zoulis schémas électriques). Il était parfaitement possible de retrouver les formules en physique note bien, mais ça m'aurait fait perdre un temps fou.
[^] # Re: Logiciels libres
Posté par lasher . En réponse à la dépêche Agrégation et logiciels libres. É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: À boire et à manger
Posté par lasher . En réponse au journal Bac et calculatrices programmables : la fin ?. Évalué à 4.
Mouais, quand j'utilise une calculatrice graphique (ou un émulateur de calculatrice graphique), j'ai un ensemble de fonctions préchargées et qui couvrent 99% de mes besoins (quelques fonctions simples et utiles pour dériver/intégrer des fonctions, faire des calculs de probas simples, etc.). Lorsque je dois faire la même chose avec un soft sur un PC, soit c'est overkill (Matlab, Maple, Mathematica, MathCAD, Octave, R, etc.)1, soit en ligne uniquement et limité si on n'achète pas une licence (Wolfram Alpha), soit je dois tout faire, ou au moins trouver par moi-même les bons modules, espérer qu'il n'y a pas de bug pour les cas simples que je veux gérer, etc… Et malgré tout, je risque de devoir en partie programmer ce que je veux faire dans ce cas, même quand ça devrait être relativement simple.
En d'autres termes, si je dois faire des maths, même simples, mais au-delà de l'arithmétique de base (en libre), il faut que je passe par Sage (calcul symbolique), R (statistiques), Octave (par ex., algèbre linéaire, et autres bidules), GnuPlot (pour tracer les courbes), ou même LibreOffice Calc, etc. Et donc je dois avoir ça sur mon téléphone portable ? Ou bien au moins avoir une sorte d'interface graphique/web qui me permette d'interroger à distance un serveur qui aura tous ces outils (à ce train-là, autant utiliser Wolfram Alpha) ?
Ça me semble un peu lourd.
Note : il existe des applications non-libres pour Android (et je suis sûr pour iOS ou Win8 aussi) qui émulent des calculatrices graphiques.
Je précise : overkill car je ne fais pas de stats poussées (R), ou de maths poussées (Matlab/Octave), ou d'algèbre poussée (Maple/Mathematica). Par contre il m'arrive de me dire « tiens, il faudrait que je dérive/intègre ceci », ou « bon, il faudrait calculer la proba que ce truc arrive », etc. ↩
[^] # Re: Choquant !
Posté par lasher . En réponse au journal Bac et calculatrices programmables : la fin ?. Évalué à 2.
Et aussi, le fait qu'on puisse vérifier que l'analyse de fonction qu'on a faite est correcte en traçant la fonction sur la calculatrice fait gagner un temps fou. Pas besoin d'une TI-{92|89}/HP{48GX,49} pour le faire cependant : la plupart des calculatrices graphiques à moins de 40€ peuvent faire l'affaire.
[^] # Re: Goto
Posté par lasher . En réponse au journal Bac et calculatrices programmables : la fin ?. Évalué à 5.
Ça a déjà été dit par d'autres, et mieux que moi, mais le contexte du papier de Dijkstra, A Case Against the Go To statement, et que la plupart nomment "Go To Considered Harmful"1, n'est absolument pas contre l'utilisation du
goto. Dans ce papier, Dijkstra est contre la programmation non-structurée, à une époque où les procédures et fonctions n'étaient pas toujours disponibles dans un langage de programmation, et où les structures de contrôle étaient parfois au mieuxif/else.Je recommande fortement la lecture (ou l'écoute) de ce monsieur, qui rappelle qu'après le papier de Dijkstra, Donald Knuth a écrit Structured Programming With
go toStatements. Notamment, Knuth rapporte une conversation (informelle) avec Dijkstra à propos dugoto:Si on traduit rapidement :
Le même article de blog référence une question (forcément un peu orientée) à propos de l'utilisation du
gotodans un module pour PHP :… qu'on pourrait traduire par
L'auteur du code explique, benchmarks à l'appui, pourquoi dans ce cas précis, l'utilisation du
gotoest la meilleure solution, tout en conservant une lisibilité satisfaisante du code et en maximisant la performance en termes de bytecode généré et de temps d'exécution. Malgré tout, des gens lui ressortent le papier de Dijkstra sans avoir sans doute compris que la décision n'était pas prise sur un coup de tête, mais au contraire mûrement réfléchie après avoir analysé les autres solutions.Bref. Lisez cet article, il est bon, il est intéressant, et il pointe vers tout plein de liens rigolos.
à cause de l'éditeur des « Communications of the ACM » qui avait reformulé le titre et soumis le papier au « courrier des lecteurs » pour que le papier court-circuite le processus de revue et soit publié plus vite. ↩
Communication personnelle avec Knuth. ↩
[^] # Re: Choquant !
Posté par lasher . En réponse au journal Bac et calculatrices programmables : la fin ?. Évalué à 2.
Hum. Ma première calculatrice graphique était une « petite » Casio qui avait coûté moins de 100FF (~15€) à mes parents. Elle était peut-être un peu juste pour le bac, mais je m'en suis servi en 2nde et première, et je n'ai eu une HP48 qu'en terminale (et d'occasion…).
[^] # Re: Ouais, ouais....
Posté par lasher . En réponse au journal Bac et calculatrices programmables : la fin ?. Évalué à 10.
Tu as raison, il suffit de copier le programme depuis un site web…
[^] # Re: Logiciels libres
Posté par lasher . En réponse à la dépêche Agrégation et logiciels libres. É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).