Puce multi-cœur contre programmeur

La parallélisation n’engendre pas plus de changement de contexte, l’argument n’est pas valide. Quant à ce concept flou qu’est "l’asynchrone", encore faudrait-il l’expliquer. Enfin si c’est le "multiplexage d’état non temporel" c’est super, c’est justement ce qu’on recherche à faire par la parallélisation (qui je le rappelle est principalement de remplacer un travail T sur A puis sur B puis sur C puis ... par T sur A en même temps que T sur B en même temps que T sur C en même temps que ...)

Je pense FB, que vous confondez avec les problèmes de concurrence, distribution (voir votre discours sur les spinlocks et autres techniques de synchronisation). Car oui, les problèmes de concurrence génèrent des incohérences dans les caches qui sont coûteuses à réparer (invalidation du cache).

... mais comme vous le dites, "la réalité est loin d’être aussi simple."

Donc avec une librairie standard genre pthread, un seul core exécute tous les traitements du programme multithreadé, même si d’autres cores sont idle par ailleurs, c’est ca ?

Le sujet est effectivement complexe, donc je précise ma pensée. En parlant de parallélisation massive je fais allusion au modèle dit des worker threads qui s’avère être une catastrophe, en cas de charge élevée les processeurs (multi-coeurs) passent leur temps à invalider leurs caches du fait des changements de contextes. Je ne critique pas le principe de la parallélisation d’algorithme avec point de rendez-vous c’est un autre (vaste) sujet.

En ce qui concerne le modèle « asynchrone », je reconnais que le mot est très mal choisi mais malheureusement c’est celui en usage. Pour prendre un exemple : celui d’un serveur web, il s’agit de faire un découpage événementiel en multiplexant sur les états des connexions ; dès qu’un paquet est reçu il est traité (même partiellement si toutes les données ne sont pas disponibles) et on repart dans la boucle événementielle. Il devient alors possible de maximiser l’utilisation des coeurs en créant un process par coeur plutôt qu’un process par connexion potentielle comme le fait le serveur web Apache.

sauf si le système affecte les threads à un autre coeur ou bien que le développeur utilise l’API fournit par le système d’exploitation pour le faire.

@dunlop,

Non. L’attribution d’un coeur à un thread est géré automatiquement par le noyau mais il est possible de suggérer l’utilisation d’un coeur particulier (sched_setaffinity()) . Néanmoins, les threads ne sont pas la panacée, les points de synchronisation peuvent coûter très cher, c’est pourquoi le développeur doit intervenir et faire un découpage intelligent pour répartir la charge, ce qui est loin d’être évident.

Titouf

Ok, donc si le noyau ou l’API peut gèrer l’attribution du thread vers tel ou tel coeur, je ne vois pas en quoi la programmation multicoeur diffère de la programmation multiprocesseur, c’est transparent pour l’application.

effectivement il y a toujours débat entre programmation multi-threadée et évènementielle, chaque méthode étant plus ou moins adaptée (facile à développer) pour telle ou telle tâche. néanmoins pour préciser un peu les choses :
1/ pour chaque méthode, il y a un changement de contexte :
 - pour les threads c’est les registres processeurs dont celui contenant la pile
 - pour l’évenementiel c’est l’évenement et sa continuation
2/ si les threads tournent dans le même espace d’adressage mémoire, il n’y a pas besoin d’invalider les caches. La différence de vitesse entre les deux méthodes est donc moins évidente.
3/ Apache gère plus ou moins toutes les configurations : mono-thread, multi-threadé, multi-processus.

fb,

D’après le dernier papier que j’ai lu à ce sujet, les performances des deux modèles seraient équivalentes. Par contre, le modèle orienté thread serait plus intuitif, donc moins sujet aux bugs de programmation. Je vais essayer de retrouver le lien.

@ dunlop

sauf quand le nombre de coeurs est supérieur au nombre de threads. Dans ce cas, il est souhaitable de pouvoir découper encore un peu plus son application. C’est là que les techniques de programmation parallèle ou distribuée sont nécessaires. Mais l’homme étant généralement faignant, c’est mieux que ce soit la machine qui s’occupe de ça.

Finalement, ces processeurs multi-coeurs servent pour des applications bien précises qui nécessitent beaucoup de puissances de calculs. Pour une utilisation traditionnelle, on devrait voir des processeurs multi-cores dont les coeurs peuvent être mis en veille. Ainsi l’utilisateur a de la puissance sous le capot sans pour autant consommer trop d’énergie.

@tytouf

Pour le 1 non. Le processeur travaille en adresses logiques pas physiques, le changement de contexte implique le rechargement de tables (LDT, TSS) et de descripteurs de segments ce qui qui peut avoir un coût véritablement très élevé si ces données ne sont pas dans le cache L1, contrairement au modèle « asynchrone ».

2. Même remarque.

3. Apache en mono thread (ça fait deux ans que je n’utilise plus Apache) ? S’il y a un lien ça m’intéresse histoire de comparer avec Nginx pour rigoler.

http://www.usenix.org/events/hotos03/tech/full_papers/vonbehren/vonbehren_h tml/index.html

c’était celui-ci il me semble.

@dunlop,

Effectivement la programmation dite « asynchrone » est plantogène, en revanche si on se donne du mal on arrive à des résultats probants si on compare avec un équivalent worker thread. Mais tout dépend aussi du problème, je me place essentiellement dans le cas d’un serveur et non pas dans celui d’une application, par exemple, de simulation numérique où les contraintes sont totalement différentes.
Si ce n’est pas du développement système et s’il n’y a pas de contraintes particulière, autant laisser faire le système, sinon il est possible de lui donner un coup de pouce ; mais après ça commence à devenir une affaire de spécialiste...

@dunlop

Merci beaucoup !
Un autre lien intéressant qui va dans le sens contraire
www.kegel.com/c10k.html 

@ fb,

reprenons les cours d’architecture et de système d’exploitation :

On appelle généralement thread ou fil d’exécution, le contexte processeur. À côté il y a ce qu’on appelle un contexte mémoire qui permet d’isoler (au niveau données) les fils d’éxécution les uns des autres. Par exemple sous Linux, un processus c’est un contexte mémoire plus un ou plusieurs fil d’éxécution. Effectivement, lors d’un changement de contexte mémoire, il faut invalider le TLB et les caches. Suivant les processeurs cette opération est plus ou moins explicite et plus ou moins couteuse (sur les derniers ARM par exemple ça coute presque rien car le cache est indexé sur les adresses physiques)

Par exemple, le scheduling de Linux travaille sur les threads, lors d’un changement de thread il vérifie si les espaces mémoires sont les mêmes. Si c’est le cas, Linux n’effectue qu’un changement de contexte processeur, sinon il change les deux contextes.

Merci fb, j’avais trouvé mon lien sur cette page justement, le monde est petit 

@dunlop

(désolé de flooder)

L’article a été publié en 2003, il s’est passé des choses entre temps ! En particulier le modèle asynchrone tire parti du principe de localité et exploite au mieux les caches L1 et L2 dans le cas de processeurs multi-coeurs. Par ailleurs l’article fait référence à /dev/poll qui est en O(n) alors que l’on dispose maintenant de epoll_wait() qui est en O(1) , enfin d’autres choses m’ont bien fait rigoler dans cet article (les 100000 threads par exemple) mais je crains qu’il ne soit quelque peu obsolète.

@tytouf,

Oui, mais dans le cas d’une architecture i386 / x86_64 avec le MMU le changement de contexte processeur a un coût, peut entraîner une invalidation des caches alors que dans le modèle asynchrone il n’en est rien. Quand il faut gérer sur un serveur 1000 connexions simultanées cela prend tout son sens (j’ai testé).

Perso, j’utilise poll() avec un seul descripteur, c’est du O(1), pas de limitation à 1024 descripteurs, c’est portable et au niveau performance, je peux gérer plusieurs milliers de connections sur un p2 350. Mais vous m’inquiétez tous les deux avec vos caches invalides. J’ai l’impression qu’un simple mutex n’est plus suffisant quand on parle multicoeur (d’ou les futex j’imagine).

Non pas de problème sur les arch intel, il y ce qu’on appelle un snoop qui s’occupe de garder la cohérence entre les caches. Sur d’autres arch par contre (ARM + DSP par exemple), il faut soit même invalider les caches.

Le « snoop » garde la cohérence soit, mais le problème n’est pas là. Si la donnée n’est pas en cache c’est catastrophique (cycle du CPU : 0,5ns, accès à la DRAM 30ns), or le changement de contexte processeur même avec le même espace de mémoire adressable peut provoquer un « cache miss » ne serait-ce qu’à cause du segment de pile. Bien évidemment plus il y a de threads plus les ratés de cache s’accumulent.