Après, de mon point de vu, je trouve ça plutôt cool qu'il est des gens (qui sont en général pas si bêtes) pour s'offusquer du multicore car ça laisse toujours des questions et réponses intéressantes sur l'intérêt du multicore qui, à mon sens, n'est pas systématique. En cela, la problématique est prise avec des pincettes pour satisfaire le plus grand nombre sans partir tête baissé sur une implémentation duquel un bon nombre de la communauté n'y serait pas regardant.
Je ne veux pas parler pour les gens qui sont farouchement opposés au multicore puisque je n'en fais pas partie. Cependant je peux faire quelques remarques qui tendent a relativiser l'importance de la disponibilité d'un système tirant partie des multiples cœurs.
Dans mon expérience professionnelle, j'ai eu à travailler sur des systèmes avec beaucoup de cœurs (environ 200) pour faire du calcul numérique (finance) et pour tirer pleinement parti de ce genre d'équipement il ne faut pas seulement paralléliser les calculs mais aussi travailler sur la localisation des données en mémoire pour éviter les mouvements de cache trop importants qui pénalisent grandement l'application. On peut bien-sûr faire du calcul numérique en OCaml ou dans n'importe quel langage de haut niveau et faire attention à la localisation des données mais certaines fonctionnalités des plateformes (de type OpenMP) sont plus faciles à utiliser dans certains langages, et puis il y a tout un écosystéme historique, comme des logiciels scientifiques (Mathematica il me semble) qui peuvent émettre du code C etc., ce qui dans l'ensemble fait qu'il est assez naturel dans ce contexte d'écrire la fonction de calcul dans un langage bas niveau et de faire un binding vers le langage de haut niveau – d'autant qu'il est relativement facile d'écrire ce type de bindings pour OCaml et Lisp, que Python est quasiment conçu "par design" comme un langage facilement extensible en C++. (Lua a aussi une FFI très facile à utiliser mais je n'ai pas encore entendu parler de gens qui font du calcul scientifique en Lua.)
Le type d'application numérique qui demande un grand nombre de cœurs sur une machine donnée est assez spécifique, il faut que le calcul utilise abondamment toute la structure initiale, autrement il est plus avantageux de faire tourner le calcul sur plusieurs machines. Pour prendre deux exemples simples, un calcul du premier genre est le calcul du carré d'une grosse matrice carrée. On peut faire un calcul par blocs en parallèle, mais cela n'est pas facile à délocaliser parceque, si par exemple si on fait 4 blocs de même taille, il faut transférer 3/4 des données pour obtenir 1/4 du résultat (et plus le nombre de blocs augmente, pire le ratio est!). Un calcul du second genre sont les calculs exploratoires faits sur une classification, où chaque fil va faire un calcul très complexe sur une petite donnée ce qui se parallélise facilement sur des machines différentes (pas forcément facile ou judicieux de louer une machine à 200 cœurs en comparaison de la location de 100 machines à 2 cœurs).
En dehors du calcul scientifique une autre application du calculs en parallèle est l'écriture de serveurs. L'approche consistant à écrire un serveur monofil dont on fait tourner un grand nombre de copies derrière un répartiteur de charge offre tellement d'avantages (logique d'application plus simple, circonscription a priori des erreurs, bugs plus facilement reproductibles, déploiement plus facile à redimensionner) qu'à la condition qu'il ne pose pas de problème de synchronisation particulier, c'est souvent la solution privilégiée.
Pour revenir au cas particulier de pijul je n'au aucune idée des algorithmes mis en jeu ni des structures de données utilisées donc je ne peux pas juger de l'avantage que ce logiciel peut tirer ou non du parallélisme léger (par opposition au fork & IPC) sur une architecture multicœur, mais dans ma petite expérience personnelle les problèmes pour lesquels ce type de parallélisme est bien adapté sont plutôt une niche qu'une généralité – surtout parceque pour que cela soit vraiment efficace il y a un travail considérable à faire sur les structures de données, travail d'autant plus critique sur les machines grand public qui ont souvent moins de mémoires cache que de cœurs. Ce n'est pas que je sois contre OCaml multicœur – et j'ai d'ailleurs bien du mal à comrpendre qu'on puisse l'être – et je serai même ravi de jouer avec lorsqu'il sera là, mais il me semble particulièrement facile de surestimer les bénéfices qu'on peut retirer de ce genre de parallélisme.
[^] # Re: Repos
Posté par Michaël (site web personnel) . En réponse au journal Pijul, un nouveau gestionnaire de source. Évalué à 6.
Je ne veux pas parler pour les gens qui sont farouchement opposés au multicore puisque je n'en fais pas partie. Cependant je peux faire quelques remarques qui tendent a relativiser l'importance de la disponibilité d'un système tirant partie des multiples cœurs.
Dans mon expérience professionnelle, j'ai eu à travailler sur des systèmes avec beaucoup de cœurs (environ 200) pour faire du calcul numérique (finance) et pour tirer pleinement parti de ce genre d'équipement il ne faut pas seulement paralléliser les calculs mais aussi travailler sur la localisation des données en mémoire pour éviter les mouvements de cache trop importants qui pénalisent grandement l'application. On peut bien-sûr faire du calcul numérique en OCaml ou dans n'importe quel langage de haut niveau et faire attention à la localisation des données mais certaines fonctionnalités des plateformes (de type OpenMP) sont plus faciles à utiliser dans certains langages, et puis il y a tout un écosystéme historique, comme des logiciels scientifiques (Mathematica il me semble) qui peuvent émettre du code C etc., ce qui dans l'ensemble fait qu'il est assez naturel dans ce contexte d'écrire la fonction de calcul dans un langage bas niveau et de faire un binding vers le langage de haut niveau – d'autant qu'il est relativement facile d'écrire ce type de bindings pour OCaml et Lisp, que Python est quasiment conçu "par design" comme un langage facilement extensible en C++. (Lua a aussi une FFI très facile à utiliser mais je n'ai pas encore entendu parler de gens qui font du calcul scientifique en Lua.)
Le type d'application numérique qui demande un grand nombre de cœurs sur une machine donnée est assez spécifique, il faut que le calcul utilise abondamment toute la structure initiale, autrement il est plus avantageux de faire tourner le calcul sur plusieurs machines. Pour prendre deux exemples simples, un calcul du premier genre est le calcul du carré d'une grosse matrice carrée. On peut faire un calcul par blocs en parallèle, mais cela n'est pas facile à délocaliser parceque, si par exemple si on fait 4 blocs de même taille, il faut transférer 3/4 des données pour obtenir 1/4 du résultat (et plus le nombre de blocs augmente, pire le ratio est!). Un calcul du second genre sont les calculs exploratoires faits sur une classification, où chaque fil va faire un calcul très complexe sur une petite donnée ce qui se parallélise facilement sur des machines différentes (pas forcément facile ou judicieux de louer une machine à 200 cœurs en comparaison de la location de 100 machines à 2 cœurs).
En dehors du calcul scientifique une autre application du calculs en parallèle est l'écriture de serveurs. L'approche consistant à écrire un serveur monofil dont on fait tourner un grand nombre de copies derrière un répartiteur de charge offre tellement d'avantages (logique d'application plus simple, circonscription a priori des erreurs, bugs plus facilement reproductibles, déploiement plus facile à redimensionner) qu'à la condition qu'il ne pose pas de problème de synchronisation particulier, c'est souvent la solution privilégiée.
Pour revenir au cas particulier de pijul je n'au aucune idée des algorithmes mis en jeu ni des structures de données utilisées donc je ne peux pas juger de l'avantage que ce logiciel peut tirer ou non du parallélisme léger (par opposition au fork & IPC) sur une architecture multicœur, mais dans ma petite expérience personnelle les problèmes pour lesquels ce type de parallélisme est bien adapté sont plutôt une niche qu'une généralité – surtout parceque pour que cela soit vraiment efficace il y a un travail considérable à faire sur les structures de données, travail d'autant plus critique sur les machines grand public qui ont souvent moins de mémoires cache que de cœurs. Ce n'est pas que je sois contre OCaml multicœur – et j'ai d'ailleurs bien du mal à comrpendre qu'on puisse l'être – et je serai même ravi de jouer avec lorsqu'il sera là, mais il me semble particulièrement facile de surestimer les bénéfices qu'on peut retirer de ce genre de parallélisme.