lasher a écrit 2732 commentaires

Un CPU au sens de von Neumann, c'est une unité centrale de traitement. Du moment que tu as un jeu de registres, une UAL, un bus de contrôle, un autre de données (qui va en mémoire) et un bus d'E/S, tu as un CPU. Point.

Pour tout le reste, ce que je comprends de ce que tu dis c'est que tu veux un CPU multi-cœur, multithreadé, avec instructions vectorielles. Tes 40 GFLOPS en simple précision, tu ne les obtiens que parce que les codes concernés sont réguliers dans les accès de données, et que tu utilises un truc genre AVX qui permet d'effectuer une opération vectorielle sur 2 groupes de 8 éléments SP. Bref, tu parles de processeurs qui sont considérés comme haute-performance. Moi aussi j'adore ces trucs, c'est même mon métier de savoir les exploiter correctement.

Ça ne veut pas dire que tous les processeurs devraient fonctionner ainsi. En fait, l'une des raisons qui a fait que l'Atom et ses potes ont commencé commercialement, c'est bien à cause/grâce à l'OLPC, qui certes utilisait une IP proprio (clone x86 par AMD ou VIA, ARM, etc.), mais qui était abordable. La fréquence était de l'ordre de 400MHz (jusqu'à 1GHz pour les modèles haut de gamme), ce qui est relativement peu. L'important était la consommation d'énergie et de puissance, histoire d'avoir une durée de vie de batterie maximale.

Tiens, une dernière remarque: la première version de Blue Gene (BG/L) était basée sur des nœuds de type PowerPC à 700 MHz. La raison était toute simple : bien qu'IBM sut faire des processeurs bien plus rapides, la mémoire, elle, ne suivait pas. Et comme l'important dans un supercalculateur, c'est le parallélisme et des latences basses bien plus que la vitesse individuelle d'un cœur de calcul, ils ont préféré avoir un système dont la technologie était quasiment complètement synchrone : le bus mémoire tournait lui aussi à 700 MHz, et les réseaux d'interconnexion entre nœuds de calculs avaient une latence qui pouvait suivre ce genre de fréquence aussi. Au final, un aller-retour entre un processeur PowerPC et la RAM prenait exactement le nombre de cycles attendus pour charger une ligne de cache (32 octets, avec un bus de 32 bits → 8 transferts = 8 cycles). En couplant cela avec des instructions de préchargement, on avait des « quasi-garanties » de ne jamais avoir de bulles dans le pipeline, sauf en cas de vraie dépendance (read-after-write), et sauf mauvaise génération de code par le compilateur bien sûr. Pourtant, le POWER5 existait déjà, et offrait une puissance brute supérieure à ce pauvre PowerPC 440 (qui est une forme de processeur embarqué).

Bon, c'est peut-être aussi ma personnalité qui est comme ça mais… Avant d'ouvrir un compte sur LinuxFR, j'ai sans doute passé ~6-10 mois à juste lire les articles et journaux (ainsi que leurs commentaires). Je fais à peu près pareil sur les forums et autres newsgroups. Tu peux considérer ça comme de l'auto-censure, mais c'est ce que je fais avec presque n'importe quel groupe de personne (IRL ou en ligne).

Pour donner une analogie un peu simpliste : lorsque j'arrive chez un nouvel ami qui me présente à ses potes, je vais rarement être celui qui initie une conversation qui ira plus loin que « salut, comment ça va ? Tu t'appelles comment ? » (avec peut-être un soupçon de « tu fais quoi dans la vie ? » et encore). Au contraire, je vais plutôt voir comment la dynamique de ce groupe d'amis fonctionne, tout en essayant de participer un peu (répondre aux questions étant un minimum). Si personne ne prononce de gros mots dans le groupe, rien ne m'interdit d'en user, mais il ne faudra pas que je m'étonne si je ne suis plus invité à fréquenter ce groupe d'amis la fois suivante (car ils m'ont trouvé vulgaire/malpoli/etc.). Encore une fois, si tu veux appeler cela de l'auto-censure, libre à toi, mais dans ce cas je ne me censure pas sur le fond, mais sur la forme : ce n'est pas parce qu'un forum est « public », dans le sens où n'importe qui peut créer un compte et participer, qu'il n'y a pas une notion d'étiquette (en dehors de celle imposée par les modérateurs du site, ainsi que les obligations légales).

Il y a toujours un risque d'acharnement de la « communauté » envers quelqu'un. Il y a aussi souvent des gens pour défendre les victimes lorsque ces dernières n'ont visiblement pas d'intentions « malhonnêtes » — le meilleur exemple est sans doute pasBillpasGates, qui a souvent été « inutilé » simplement à cause du fait qu'il bossait pour MS et qu'il corrigeait des affirmations (souvent incomplètes, voire fausses) concernant les produits de Microsoft. Zenitram l'a défendu (souvent); je l'ai défendu (parfois); d'autres l'ont défendu aussi, et tu peux être certain qu'une grande partie est en désaccord la moitié du temps avec pBpG. Malgré ça, il en a eu marre à un moment car il était traité de façon réellement injuste. Et en réaction à ça, il y a eu un (des?) journaux, etc., pour défendre pBpG, et il a finalement eu son score réinitialisé, et il lui arrive encore de temps en temps de venir commenter (et s'engueuler joyeusement avec nous).

Bref, comme tout groupe de personnes, il existe des fois où certains ne s'intègrent pas bien. Mais s'ils ont pris le temps de lire un peu comment les gens argumentent ici, ils savent qu'en fonction de qui répond, le style est plus ou moins sec, violent, abrasif, condescendant, etc., ou au contraire plutôt très ouvert. C'est toujours pareil : si tu « imites » le style des plus violents des contributeurs de LinuxFR, attends-toi à obtenir des réponses tout aussi violentes. Au contraire, si au moins au début tu restes relativement neutre, pour tater le terrain, tout en exposant tes idées, j'ai rarement vu des gens sur DLFP qui t'envoyaient bouler méchamment (gentiment, oui; ironiquement, oui; avec contre-arguments, oui; sans contre-arguments, oui; etc.).

Pour finir avec une analogie pourrie : disons qu'un pote me présente à un autre de ses potes. Mon pote dit bonjour son ami en disant « Salut connard ! » Si l'ami en question le prend bien, c'est très certainement ironique, ils se connaissent bien, et donc ne vont pas voir autre chose qu'une blague de mauvais goût potache. Si ensuite je dis la même chose, l'ami de mon pote peut à juste titre me regarder de travers, m'insulter en retour (et cette fois être sérieux), etc., et ce sera ma faute. J'aurais du dire « Bonjour » poliment la première fois, car je ne connais pas assez bien ce monsieur (ou cette dame) pour me permettre de lui parler aussi familièrement.

C'est rigolo, je n'avais lu que les 4 premiers mots (« Teradata investit dans DotHill »), et je savais déjà que ce serait un des journaux de Samuel. :-)

Tu as raison pour les micro-benches, mais si d'un côté tu ne vas sans doute pas exécuter 10000 fois le même noyau de code d'affilée, tu vas par contre réutiliser les mêmes structures de données régulièrement, en leur faisant subir plusieurs types de traitements. De ce côté-là, ça signifie que oui, tu auras au moins une partie des structures de données présentes dans les caches.

Personnellement j'aime faire les deux :

1. Une série de tests où je vide systématiquement les caches avant de faire tourner le code
2. Une série de tests où je répète le même code plusieurs fois de suite pour voir quel est la meilleure performance possible en pratique (vs. la performance théorique de la machine par exemple).

Dans le cas précis de Python, c'est beaucoup plus compliqué, car le ramasse-miettes, les mécanismes dynamiques de typage, etc., font que des traitements annexes au code lui-même peuvent se déclencher de façon complètement imprévisible.

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).

C'est mon problème avec ce benchmark:

1. Je ne sais pas quel code a été utilisé pour faire les benchmarks
2. Je ne comprends pas leurs métriques en termes de perfs (pour la puissance, c'est assez clair)

Bref, j'aimerais avoir quelqu'un qui m'explique un peu comment lire les graphes.

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:

1. 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);
2. dans les années 90, Cilk a permis de créer l'un des meilleurs programmes d'IA d'échecs pour machine parallèle;
3. 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;
4. 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élisme¹

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 secondaire¹. 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).

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.)¹, 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.

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.