Comme nous l’avons déjà dit, l’ajout du second core est inutile pour un très large pan d’applications monothread. Cette solution est également très coûteuse en terme de ressources vu qu’elle double le nombre de transistors. Enfin, même pour les applications futures il y a de nombreuses contraintes à la programmation multithread qui font que cela demandera de nombreux efforts aux développeurs pour en tirer réellement profit, si tant est que l’application s’y prête bien initialement.

Le problème fondamental est que notre cerveau n’arrive pas à suivre le déroulement d’un programme parallèle, nous ramenons inévitablement tout à une exécution séquentielle au final et les programmeurs ont beau être des gens bizarres aux yeux des autres personnes, ils n’en sont pas pour autant différents sur ce point. Et une fois ce premier obstacle franchi il en reste beaucoup d’autres. Il est ainsi courant de tomber dans des cas d’interblocage où chaque thread capture une ressource et attend que l’autre libère la sienne pour continuer. Un autre problème est celui de la famine où un thread tente désespérément d’acquérir une ressource à des moments où elle n’est jamais disponible (les joies de l’ordonnancement !). Tous ces problèmes sont connus depuis plusieurs dizaines d’années et ont été illustrés notamment par le célèbre problème des philosophes de Dijkstra. Il existe évidemment des solutions à tous ces problèmes mais comme bien souvent elles ne s’acquièrent qu’avec une certaine expérience de la programmation parallèle.

Le principal fléau de la programmation parallèle reste l’aspect non déterministe de certains bugs. Du fait de l’ordonnancement des threads il n’est en effet pas toujours possible (il serait en fait plus correct de dire « souvent impossible ») de les reproduire avec un scénario type, ce qui rend le débuggage d’une application threadée long et fastidieux. Pire encore : certaines applications multithreadées marchant parfaitement sur des machines monoprocesseur peuvent révéler des bugs sur des machines multiprocesseurs ! Un véritable casse tête pour le programmeur. Et si malgré tout ça le programmeur parvient à se sortir de ce guêpier informatique alors peut être constatera-t-il un gain significatif de performances… ou peut être pas ! Il est en effet très facile de perdre tous les gains obtenus à l’exécution dans de trop nombreuses communications entre les processeurs ou par un mauvais découpage en threads insuffisamment indépendants et se battants pour l’accès à une ressource partagée, ce qui a pour effet de rendre l’exécution finalement séquentielle.

Vu les problèmes qu’implique la programmation parallèle il est compréhensible de voir les développeurs se concentrer sur une petite partie du code sur laquelle les bénéfices seront les plus importants. Il y a un adage courant en programmation qui dit que tout programme d’une certaine taille passe 80% de son temps dans 20 % du code. C’est donc cette partie du code qu’il convient d’optimiser. Si nous nous plaçons dans le cadre d’un jeu par exemple les principaux candidats à un découpage en thread sont les suivants :

• Le moteur physique
• Le moteur sonore
• La traversée du graphe de scène

Le moteur de rendu pour sa part est un cas un peu particulier, c’est un gros consommateur de ressources CPU mais la plupart du temps est passé à l’intérieur du driver de la carte graphique et le driver est par nature séquentiel vu qu’il communique avec le GPU qui est une machine à états. Malgré tout, plusieurs processeurs sont tout de même profitables dans cette situation car le temps passé dans le driver est moins déterminant pour les performances vu que l’autre CPU est libre à ce moment. Plutôt donc que de se battre pour threader le moteur de rendu qui ne s’y prête vraiment pas, il vaut mieux s’assurer que le reste du code est suffisamment bien parallélisé afin que lorsque le thread de rendu est bloqué dans le driver, les autres CPU puissent effectuer un travail utile.

La bonne nouvelle c’est que tout n’est pas aussi noir que nous l’avons laissé paraître : il existe des outils pour aider le programmeur à paralléliser son code qu’il s’agisse de l’API OpenMP ou de certains compilateurs « autoparallélisants » comme le compilateur C++ d’Intel.

La mauvaise nouvelle maintenant est que ces outils sont en très grande partie inutiles ! Plus sérieusement disons qu’ils ne résolvent pas les problèmes fondamentaux de la programmation parallèle. Ils sont peut être capables de paralléliser certaines boucles ou de rendre la vie du programmeur un peu moins pénible mais il ne faut pas s’attendre à les voir générer un code multithread optimal à partir de n’importe quelle « soupe » venue. Par conséquent les gains à attendre de la part de ce genre d’outils sont modestes tout au plus. Pour tirer au mieux parti des avantages offerts par les processeurs multi core il faut repenser ses algorithmes pour les adapter à une forme qui se prête bien au parallélisme, et ça aucun compilateur n’a une connaissance du programme pour le faire à la place du programmeur.