fb

Un compilateur ou un interpréteur n’a pas connaissance de la sémantique du programme et ne peut que faire des choix arbitraires ; l’utilisation efficace d’un système multi-coeur nécessite l’intervention du développeur ou tout du moins le choix d’une architecture adaptée. Dans le cas d’une application bureautique ce n’est pas un problème mais dès lors qu’il y a des calculs intensifs ou que cela concerne un serveur cela fait toute la différence.

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

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.

Mouaip, Charles tu as été plus inspiré dans d’autres articles...

Concernant la programmation parallèle massive, les multi-coeurs sont particulièrement inadaptés à cause des invalidations de cache inhérentes aux commutations de contextes engendrées. La nouvelle tendance en matière de programmation efficace consiste plutôt à aller vers l’asynchrone (multiplexage d’état non temporel) en opposition avec le paradigme venant d’Unix (un client égal un serveur égal un process ou un thread plus multiplexage temporel).
Intel veut faire croire que ses processeurs sont excellents et que les programmeurs sont en retard mais qu’un super outil de développement résoudra le problème, la réalité est loin d’être aussi simple.
S’il est vrai que les programmeurs doivent se faire violence pour tirer parti des qualités des processeurs multi-coeurs (et surtout pour éviter leurs défauts), malheureusement un très faible pourcentage sera en mesure d’intégrer des notions comme les spinlocks, futex, RCU, barrières... pourtant essentielles à la synchronisation des coeurs.
En revanche, l’intégration CPU+GPU pourrait donner lieu à des choses très intéressantes, mais en l’absence de normalisation entre Nvidia et ATI cela reste hypothétique sans compter que cela fait belle lurette que les serveurs n’ont plus de carte vidéo 

PS : désolé pour les acronymes divers et variés difficilement explicables en commentaires.

Pas quand un proxy est imposé, ce qui est le cas des opérateurs télécom du sans fil qui justifient cela en expliquant que cela permet de réécrire les pages à la volée pour que ce soit lisible sur un écran de téléphone.