En effet ça demande de comprendre ce que l'on fait et comment ça marche. Tout comme en séquentiel tu as besoin de comprendre à la fois la complexité et les performances/implication de l'implémentation, en parallèle tu as besoin de comprendre si tes opérations sont scalable et où/pourquoi l'implémentation va poser problème.
Il n'y a rien de magique. Par contre offrir des outils simples et performants entre le purement séquentiel et le programme purement parallèle et/ou distribué n'est pas stupide. Tu as pas mal d'applis ou il y a à gratter sans sortir des archis compliquées.
Le monde n'est pas binaire:
le GC parallèle (qui tourne en même temps que les threads au lieu de les stopper) a été désactivé car il dégradait les performances soit très bien pour le batch, maintenant comment je garantie que mon appli n'aura jamais un temps de réponse > 20ms ? Comment je minimise mon jitter ? Différents besoins, différentes solutions.
les implémentations qui scalent le mieux (x6 sur 8 cœurs) sont 10 fois plus lentes que la version séquentielle quand elles tournent sur un seul cœur c'est exactement pour ca que ce n'est pas automatique et qu'il faut un cerveau derrière. Maintenant vu la gueule des chiffres, j'ai envie de dire que ca ressemble un problème de l'implem d'Haskell.
l'implémentation la plus rapide utilise 8 cœurs pour multiplier les performances par 3 par rapport à la version séquentielle c'est effectivement un gros problème et c'est pour ca qu'on ne cherche qu'à exposer les patterns qui scalent. D'ailleurs en général les patterns qui scalent en parallèle et distribués sont assez similaires. Ca veut dire que tu vas petit à petit tordre les conceptions des projets pour être distribuable. C'est très bien.
Autre question, ce sont quoi les autres alternatives ? Quel est le coût et la performance d'une approche explicite ? Quel sont les coût et les performance de tout autre approche ? C'est cool, et parfaitement valide, et dire que telle approche a des perfs moisi. Maintenant je fais quoi de mes 7..31 autres cores ? Je fais comment quand l'approche séquentielle ne peut pas tenir les perfs nécéssaire ?
Il est aussi vrai qu'à la base le design en FP se prête mieux à la parallélisation. En OOP la plupart des gens sont encore sur des designs aux états mutables, au partage de donnée, à la synchronisation dont on connait en général les perfs, la complexité et la scalabilité. Maintenant on cherche des solutions, pas magiques mais qui font leur job. Les besoins des utilisateur sont très divers, explorons différentes solutions.
[^] # Re: Pour paralleliser du code en OCaml, c'est par ici:
Posté par ckyl . En réponse à la dépêche Sortie du livre « Parallel and Concurrent Programming in Haskell ». Évalué à 6.
En effet ça demande de comprendre ce que l'on fait et comment ça marche. Tout comme en séquentiel tu as besoin de comprendre à la fois la complexité et les performances/implication de l'implémentation, en parallèle tu as besoin de comprendre si tes opérations sont scalable et où/pourquoi l'implémentation va poser problème.
Il n'y a rien de magique. Par contre offrir des outils simples et performants entre le purement séquentiel et le programme purement parallèle et/ou distribué n'est pas stupide. Tu as pas mal d'applis ou il y a à gratter sans sortir des archis compliquées.
Le monde n'est pas binaire:
Autre question, ce sont quoi les autres alternatives ? Quel est le coût et la performance d'une approche explicite ? Quel sont les coût et les performance de tout autre approche ? C'est cool, et parfaitement valide, et dire que telle approche a des perfs moisi. Maintenant je fais quoi de mes 7..31 autres cores ? Je fais comment quand l'approche séquentielle ne peut pas tenir les perfs nécéssaire ?
Il est aussi vrai qu'à la base le design en FP se prête mieux à la parallélisation. En OOP la plupart des gens sont encore sur des designs aux états mutables, au partage de donnée, à la synchronisation dont on connait en général les perfs, la complexité et la scalabilité. Maintenant on cherche des solutions, pas magiques mais qui font leur job. Les besoins des utilisateur sont très divers, explorons différentes solutions.