Discussion :

[Idelways]

L'inventeur du XML plaide pour la programmation concurrente et fonctionnelle
Elle serait mieux adaptée aux progrès liés aux CPU multi-coeurs



Lors d'une présentation à l'O'Reilly Open Source Convention 2010, Tim Bray, le co-inventeur du XML, a fortement plaidé pour la programmation concurrente et fonctionnelle.

Au lieu d'utiliser des threads, la programmation fonctionnelle présenterait, d'après lui, une meilleure approche pour les développeurs qui doivent réaliser des programmes pour les processeurs multi-coeurs

La programmation pour les CPU multi-coeurs amène en effet son lot de problèmes, au premier rang desquels la simultanéité. Ces nouveaux problèmes (dont les goulets d'étranglement), seraient des « problèmes très difficiles à appréhender ou à comprendre », a-t-il souligné.

La programmation fonctionnelle, paradigme des langages comme Erlang et Clojure, permettrait de mieux les solutionner, et donc de mieux gérer cette simultanéité.

La programmation fonctionnelle repose sur le principe que les données ne sont pas partagées. Conséquence, les développeurs n'ont pas à se soucier de savoir si elles changeront, ce qui « permet de désigner les données au lieu de les envoyer », souligne Bray.

Erlang (conçu pour la programmation massive des Switch téléphoniques avec des centaines voire des milliers de processeurs) est par exemple un langage qui n'a ni classes, ni objets, ni variables. Sa gestion des fichiers est « misérable ». Mais il resterait particulièrement approprié et puissant pour gérer le multi-coeur.

Idem pour Clojure, « un langage de très, très hautes performance » pour Bray. Clojure est un Lisp qui fonctionne sur la machine virtuelle Java et qui compile en code Java classique. Ses performances en terme de vitesse sont remarquables.

La thèse de la démonstration de Bray est de dire que gérer la simultanéité avec le threading n'est pas une mauvaise idée en soi. Mais cette programmation avec les threads (qui offre de multiples accès à partager, des données mutables, etc) est mal, voire pas du tout comprise.

Pire, elle « ne sera jamais comprise par les développeurs d'applications », provoque-t-il.

Faudrait-il donc tout revoir à zéro pour accompagner l'évolution du hardware ?

C'est un peu ce que pense Bill Dally, un des ingénieurs les plus importants de Nvidia, mais dans un registre différent lorsqu'il écrit dans Forbes « après 40 ans de programmation linéaire [il faudrait] une rupture avec les pratiques de longue date ».

Et de regretter le manque de formation des développeurs dans la programmation parallèle et les technologies propres aux multi-coeurs.

Deux visions pour un même constat : le multi-coeurs n'a pas fini d'être un défi pour les développeurs.


Source : Site de l'O'Reilly Open Source Convention 2010


Lire aussi :

Quel langage pour la JVM est pour vous promis à un bel avenir ?

Qu'est-ce qu'un langage fonctionnel


Les rubriques (actu, forums, tutos) de Développez :

Hardware
Langages


Et vous ?

Pratiquez-vous de la programmation concurrente ou fonctionnelle ?

Dans l'ère du multicoeurs, pensez-vous comme Bray que les paradigmes de programmation fonctionnelle et concurrente soit plus adaptés ?


En collaboration avec Gordon Fowler

[Invité]

Programmation parrallèle selon Intel : http://software.intel.com/en-us/parallel/
Pour ceux qui ont du temps devant eux !
Threads are evil : Avoid them ! (D. Richard Hipp sqLite)
The problem with threads (Edward A. Lee Berkeley) :
http://www.eecs.berkeley.edu/Pubs/Te...ECS-2006-1.pdf

Sinon, les telecoms se prêtent très bien au multithread contrairement au reste.
La règle "Un thread = un device (telecom, GPU, sound, ...)" fonctionne pas trop mal.
En traitement de raw input : division du raw par le nombre de core : marche parfois aussi (sauf si agregation) (zip, flat, trt de signal)
SGBD : monothread obligatoire (voir titre).
Le reste est un casse tête à moins de faire "dormir" les threads pour.. imiter le monothread par synchronisation... J'espere que les core48 supporteront le turbo-boost.

C'est un peu ce que pense Bill Dally, un des ingénieurs les plus importants de Nvidia, mais dans un registre différent lorsqu'il écrit dans Forbes « après 40 ans de programmation linéaire [il faudrait] une rupture avec les pratiques de longue date ».

D'accord avec ce qu'il dit, c'est même exactement ce que je dis aussi, sauf que ça ne dit pas qu'on pourra faire en parrallèle ce qu'on fait en séquentiel et personnellement j'en doute. Comme tout le monde l'exige, je ne demande qu'à apprendre mais parfois.. l'info n'est pas là !
Et la solution non plus..

Multicore et multi servers sont des disciplines très voisines pour le traitement. J'ai fait un peu des deux mais peut-être qu'un grand maître du multi-server pourrait donner quelques trucs et astuces....

[amaury pouly]

Programmation parralèle selon Intel : http://software.intel.com/en-us/parallel/
Pour ceux qui ont du temps devant eux !
Threads are evil : Avoid them ! (D. Richard Hipp sqLite)
The problem with threads (Edward A. Lee Berkeley) :
http://www.eecs.berkeley.edu/Pubs/Te...ECS-2006-1.pdf

Sinon, les telecoms se prètent très bien au multithread contrairement au reste.
La règle "Un thread = un device (telecom, GPU, sound, ...)" fonctionne pas trop mal.
En traitement de raw input : division du raw par le nombre de core : marche parfois aussi (sauf si agregation) (zip, flat, trt de signal)
SGBD : monothread obligatoire (voir titre).
Le reste est un casse tête à moins de faire "dormir" les threads pour.. imiter le monothread par synchronisation... J'espere que les core48 supporteront le turbo-boost.

D'accord avec ce qu'il dit, c'est même exactement ce que je dis aussi, sauf que ça ne dit pas qu'on pourra faire en parrallèle ce qu'on fait en séquentiel et personnellement j'en doute. Comme tout le monde l'exige, je ne demande qu'à apprendre mais parfois.. l'info n'est pas là !
Et la solution non plus..

Multicore et multi servers sont des disciplines très voisines pour le traitement. J'ai fait un peu des deux mais peut-être qu'un grand maître du multi-server pourrait donner quelques trucs et astuces....

Je dois voir le mal partout mais en quoi cet article est-il pertinent ? En gros il dit "les threads c'est mal" parce que c'est non-déterministe. Il dit aussi que le non-déterminisme c'est mal. Or certaines tâches sont non-déterministes. Si le code a une partie GUI et une partie calcul, une intervention de l'utilisateur est une action non-déterministe.

Je pense qu'on peut tourner le problème comme on veut, faire du message passing, faire des diagrammes et tout ce qu'on veut mais le problème fondamental c'est de faire plusieurs choses à la fois et cela nécessitera toujours de la synchronisation et donc il y aura un risque de bug.

On parle aussi beaucoup de la programmation fonctionnelle pour le calcul en parallèle et c'est vrai que c'est tentant étant donné que toutes les structures de données sont en lecture seulement. Toutefois, cela cache aussi ses propres problèmes. Par exemple, en fonctionnelle, tout est en lecture mais comme on écrit ? En créant des objets ! Or créer des objets demande de la mémoire qu'il faut allouer et libérer. Donc le problème n'a pas disparu.
Par ailleurs, on peut aussi perdre en performance puisque l'idée de la plupart des structures de données fonctionnelle c'est qu'on a l'intégralité de l'historique des modifications. En pratique cela veut dire que si on une structure A et qu'on veut la modifier pour obtenir B alors on représente B par représente A + modification. Autrement dit on se retrouve avec un empilement de modifications qui si elles ne sont pas bien faites seront moins performantes.
Bref, ce que je veux dire c'est que le fonctionnel d'accord mais en réalisant que ce n'est pas gratuit et que les problèmes sont encore là mais sous d'autres formes.

[S(ô.Ô)B]

Pour avoir déjà fait de l'Erlang, je suis tout à fait d'accord avec amaury pouly, lorsqu'on programme en fonctionnel pur comme Erlang d'autres problèmes apparaissent, et souvent pas des moindres. Mais ce langage est vraiment intéressant et j'invite tout le monde à y jeter un coup d'œil ne serait-ce que pour sa gestion de la modification du code à chaud, ou du parallélisme sur plusieurs machines déconcertant de facilité à mettre en place.

Après par rapport à l'intervention de Tim Bray, qui dit en gros que les threads c'est le mal car les données sont partagées, et ben avec un peu de discipline et de rigueur de programmation on peut très bien travailler qu'avec des données propres à chaque thread...

[Invité]

Je dois voir le mal partout mais en quoi cet article est-il pertinent ? En gros il dit "les threads c'est mal" parce que c'est non-déterministe. Il dit aussi que le non-déterminisme c'est mal. Or certaines tâches sont non-déterministes. Si le code a une partie GUI et une partie calcul, une intervention de l'utilisateur est une action non-déterministe.

Je pense qu'on peut tourner le problème comme on veut, faire du message passing, faire des diagrammes et tout ce qu'on veut mais le problème fondamental c'est de faire plusieurs choses à la fois et cela nécessitera toujours de la synchronisation et donc il y aura un risque de bug.

On parle aussi beaucoup de la programmation fonctionnelle pour le calcul en parallèle et c'est vrai que c'est tentant étant donné que toutes les structures de données sont en lecture seulement. Toutefois, cela cache aussi ses propres problèmes. Par exemple, en fonctionnelle, tout est en lecture mais comme on écrit ? En créant des objets ! Or créer des objets demande de la mémoire qu'il faut allouer et libérer. Donc le problème n'a pas disparu.
Par ailleurs, on peut aussi perdre en performance puisque l'idée de la plupart des structures de données fonctionnelle c'est qu'on a l'intégralité de l'historique des modifications. En pratique cela veut dire que si on une structure A et qu'on veut la modifier pour obtenir B alors on représente B par représente A + modification. Autrement dit on se retrouve avec un empilement de modifications qui si elles ne sont pas bien faites seront moins performantes.
Bref, ce que je veux dire c'est que le fonctionnel d'accord mais en réalisant que ce n'est pas gratuit et que les problèmes sont encore là mais sous d'autres formes.

Parlez vous de l'article développez ?
De la blague de R.Hipp ? j'aime bien ce gars car il a eu du succès , n'appartient à aucune grosse compagnie et a une vision très scandinave du monde, donc il parle comme ça lui vient et dit bien haut ce que tout le monde murmure ...

Les questions de thread ne datent pas du premier multicore , cela existe depuis Unix. Or s'il est vrai que des virtuoses ont posé les jalons d'un certain multithreading , il s'agit le plus souvent de software réseau-telecom. Cela concerne un petit nombre de développeurs. Un exemple parlant est l'usage que FTP fait des caractères jokers.

Pour le reste, dans le meilleur des cas , on a des synchros encombrantes en code comme en cpu. Dans les cas plus tordus, on modifie la structure du programme pour gérer des evènements soit existants dans le framework soit réécrit à la main (boucles infinies ...) C'est de cette manière qu'on peut quand même faire de la BDD asynchrone (multithread donc) même si M Hipp ne nous le conseille pas. En effet, il ne suffit pas d'orchestrer une messagerie interne : on a aussi des problèmes d'accès concurrent qu'on gère en interne avec des delegates mais ça ne suffit pas non plus et notamment dans le cas de R.Hipp et son sqlite qui n'est pas très multi-users mais c'est juste un cas parmi d'autres.

Donc le deal est : désormais le multithread n'est plus une amélioration des techniques existantes mais une nécessité rendue obligatoire par l'industrie des processeurs qui n'arrive plus à monter en fréquence (je résume beaucoup)

Avant que nos élites nous demandent de tout refaire en multithread , je crois urgent de dire que le multithread n'est pas une bonne solution sauf pour les telecom+++ et dans une moindre mesure quelques problèmes pas trop itératifs(GPU?..). Mais que pour un très grand nombre de cas, ils n'apportent absolument rien , si ce n'est un paquet d'ennuis avec du software qui marchait très bien en monothread..

Plus proche de l'utilisateur on peut designer du fonctionnel astucieux et très spécifique pour lui rendre la vie plus agréable, mais pour conclure je dirais surtout :

Le software ne peut pas gagner avec le multithread autant que le hardware actuellement. Un processeur à 48 coeurs ne sera jamais 48x plus rapide mais il pourra faire le travail de 48 machines auparavant .. Peut-être avez vous des idées de formulation plus diplomatique (je suis preneur)

[pseudocode]

Plus proche de l'utilisateur on peut designer du fonctionnel astucieux et très spécifique pour lui rendre la vie plus agréable, mais pour conclure je dirais surtout :

Le software ne peut pas gagner avec le multithread autant que le hardware actuellement. Un processeur à 48 coeurs ne sera jamais 48x plus rapide mais il pourra faire le travail de 48 machines auparavant .. Peut être avez vous des idées de formulation plus diplomatique (je suis preneur)

Je pense que l'idée de l'article c'est de dire que les langages impératifs obligent le développeur à concevoir son application en Mono-thread ou en Multi-thread. Mais une fois que ce choix est fait, il est immuable (sauf a réécrire l'application).

Les paradigmes fonctionnels/concurrentiels sont là pour ne pas solutionner ces problèmes par la conception, et donc repousser "au plus tard" (compilation, run-time) les optimisations relatives aux multi-coeurs.

[Invité]

Je pense que l'idée de l'article c'est de dire que les langages impératifs obligent le développeur à concevoir son application en Mono-thread ou en Multi-thread. Mais une fois que ce choix est fait, il est immuable (sauf a réécrire l'application).

Les paradigmes fonctionnels/concurrentiels sont là pour ne pas solutionner ces problèmes par la conception, et donc repousser "au plus tard" (compilation, run-time) les optimisations relatives aux multi-coeurs.

C'est plutôt rassurant quant aux demandes à venir.. En fait les notions que je développe consistent aussi à présenter aux décideurs non-spécialistes, afin de faire comprendre la situation avec des termes qu'ils peuvent comprendre.

Dans ce domaine plus qu'ailleurs, je crains des demandes irréalistes formulées par des élites qui se laisseraient séduire par un discours peu compréhensible. Cela m'est arrivé avec des spécialistes du hardware plutôt haut-de-gamme. Ils sont très compétents et donc très écoutés. Leur impression est que le soft ne suit pas parce que les développeurs n'utilisent pas les bonnes techniques. Si vous relisez l'article, vous verrez que cette confusion est parfaitement possible.

Par protocole ou par politesse , on en oublie de préciser que le soft est un peu à la masse par rapport au hard dans cette histoire. Ce n'est pas vraiment une histoire de techno ou de méthode. Ce que les fondeurs présentent comme une avancée majeure, n'en est pas vraiment une pour le software.

Ce qui aurait vraiment permis d'améliorer nos affaires, ce sont des micro-codes plus rapides ou des fréquences d'horloge supérieures. Le multicore quant à lui ne permet que d'améliorer une partie du logiciel et risque de ralentir le reste.

C'est pourquoi le turbo-boost d'intel est si interressant dans les core i5 et i7. Actuellement, cette question est traitée dans la presse d'une façon qui laisse planer un doute sur la compétence du software.

Ce doute n'est pas vraiment une bonne chose. Il faudra du temps pour qu'il se dissippe. Personnellement, je ne suis pas en position de faire avancer les choses de façon crédible, je ne peux que donner une position que certains peuvent très bien interpréter comme défensive.

Je n'ai pas très envie de faire beaucoup de recherche sur le multithread car je devine que le potentiel d'optimisation monothread est bien meilleur.
En appliquant bêtement ce qui saute aux yeux : une FFT multithread : même Einstein ne saurait pas le faire. Une FFT 3D (plusieurs FFT's), oui on peut le faire massivement parrallèle même avec un langage ancien. (cela annonce de grandes améliorations lecture mpeg et divx) Et quid d'un simple QuickSort sur un index d'un milliard d'entrées ? comment comparer une ligne si on n'est pas sûr qu'un autre thread ne l'a pas déjà swappée ?

Une boucle for(; ; ) parallèle : ça existe depuis longtemps déjà mais si cette boucle fait appel à des calculs issus de la boucle précédente, ça ne marchera jamais. Ce n'est pas une question de langage ou de méthode : c'est physiquement impossible. Tout le monde ne comprend pas forcément ça comme un ingénieur qui passe ses journées dans le code.. les notions de récursion, d'itérativité, ... ne sont pas maîtrisées par grand monde et pas spécialement par les électroniciens qui ne s'en servent pas dans leur travail d'après ce que j'ai compris.

[pseudocode]

Dans l'ère du multicoeurs, pensez-vous comme Bray que les paradigmes de programmation fonctionnelle et concurrente soit plus adaptés ?

Oui. Mais ce n'est pas pour autant qu'il faut vouloir enterrer la programmation impérative. Remplacer les programmes 100% impératif par des programmes 100% fonctionnel c'est un peu extrème comme approche.

Je préfèrerai que les langages impératif traditionnels évoluent pour intégrer proprement les paradigmes fonctionnels/concurrents. On n'a pas tout le temps besoin de penser en multicoeurs.

[oxyde356]

Ca commence à être un peu fatiguant tous ces spécialistes qui veulent prendre les développeurs par la main et les pousser vers des solutions plus simples mais jamais plus performantes contrairement à ce qui est dit, bien au contraire. Je trouve que cette politique est responsable de l'abaissement du niveau des développeurs comme l'a été le mouvement massif vers Java ... si on continue comme ça on ne va faire plus que des scripts

[zul]

Pour intégrer proprement le fonctionnel, il faut commencer par intégrer le concept de fonction pure (ou transparence référentielle ou autre terme à la mode) qui est en soit assez contradictoire avec impératif.

Je ne vois pas bien où est la simplification. Il dit juste que d'utiliser des paradigmes différents que le sacro-saint objet-impératif pourrait s'avérer judicieux pour gérer les problématiques "multi-//". À mon avis, ça ne se fera justement pas rapidement, parce que c'est compliqué : ce n'est pas juste voir de syntaxe comme entre Java / C# / autre clone objet, mais profondément repensé les paradigmes à utiliser / les architectures qui vont avec.

Erlang en soit n'est pas extrêmement performant sur un seul score, mais il passe bien à l'échelle sur n-core / n-machines (sans compter la gestion des nodes qui tombent etc ...).

[Julien Bodin]

Je trouve que cette politique est responsable de l'abaissement du niveau des développeurs comme l'a été le mouvement massif vers Java ... si on continue comme ça on ne va faire plus que des scripts

C'est quoi ce vieux troll ?

[oxyde356]

C'est quoi ce vieux troll ?

Je n'avais aucunement l'intention de pourrir Java, je l'ai pris au hasard