Peut-on créer un programme à thread unique pour utiliser plusieurs cœurs?

Le titre dit tout: existe-t-il un moyen d'obtenir un ancien programme conçu pour utiliser un seul cœur de processeur pour utiliser plusieurs cœurs de processeur?

Malheureusement, un programme hérité écrit pour un seul processeur ne peut pas être obligé d'utiliser plusieurs cœurs de processeur. L'utilisation de plusieurs cœurs de processeur nécessite plusieurs threads, qui doivent communiquer entre eux tout en garantissant que les conditions de concurrence et d'autres problèmes ne se produisent pas. Une application plus ancienne ne peut pas être utilisée pour utiliser plus que le cœur du processeur, sauf si elle est réécrite pour le faire, et uniquement si la nature de l'application permet de la paralléliser.

Quel est votre objectif? Des performances accrues? Malheureusement, les applications conçues pour n'utiliser qu'un seul cœur n'en utiliseront pas plus. C'est de cela que parlent ces applications "multi-thread".

Il existe au moins trois techniques pour exploiter plusieurs processeurs dans un programme conçu pour utiliser un seul cœur. La plus simple de ces techniques consiste à utiliser des bibliothèques et du code système qui utilisent plusieurs cœurs ou peuvent s'exécuter au moins partiellement en parallèle avec le code d'application. Le garbage collection est un exemple de fonctionnalités qui peuvent être parallélisées et qu'il est possible de faire en parallèle avec l'exécution de l'application. Même sans gestion automatique de la mémoire, il existe un certain potentiel de parallélisme dans les fonctions de désallocation de mémoire car l'allocateur de mémoire peut avoir un travail à faire au-delà du simple marquage de la section de mémoire comme disponible.

Une deuxième technique est la traduction binaire. Bien que cela puisse être considéré comme une «réécriture de l'application», cela se fait par logiciel et sans accès au code source. La production de parallélisme au niveau des threads ne semble pas avoir été le principal objectif de la plupart des recherches et développements utilisant la traduction binaire (qui concerne souvent l'exécution de code hérité sur une autre ISA, l'exploitation des extensions ISA ou l'optimisation pour une microarchitecture particulière, et l'utilisation d'informations dynamiques pour fournir des résultats plus élevés). optimisation guidée par le profil de qualité), mais le potentiel est évident.

Une troisième technique est le multithreading spéculatif. Actuellement, aucun processeur (à ma connaissance) ne prend en charge le multithreading spéculatif géré par le matériel. Cependant, avec l'introduction de la mémoire transactionnelle matérielle, la mise en œuvre d'un tel système d'exécution devient un peu plus pratique car le HTM peut être utilisé pour détecter les conflits d'utilisation de la mémoire. Le multithread spéculatif géré par logiciel impliquerait généralement une traduction binaire, mais sa nature spéculative justifie d'envisager une technique distincte.

Le caractère pratique de ces techniques est limité par les coûts associés aux systèmes existants (y compris le coût de communication entre les threads et les threads de frai), par le parallélisme limité qu'ils peuvent exploiter et par le retour sur investissement limité (applications importantes qui peuvent être avantageuses parallélisés sont susceptibles d'être réécrits, de nombreuses applications bénéficieraient relativement peu voire pas du tout de ces techniques (en particulier avec des limites de puissance / thermique permettant à un seul cœur de fonctionner à une fréquence plus élevée que plusieurs cœurs), et les coûts de développement sont importants). Cependant , ces techniques ne existent et il est théoriquement possible d'utiliser plusieurs cœurs avec une application conçue pour utiliser un seul noyau.

Non ça ne peut pas être. Un programme est explicitement écrit pour utiliser plusieurs cœurs. Il n'est pas trivial de faire le travail dans plusieurs cœurs. Il nécessite des synchronisations de tous les threads. Comme on lance le ballon, l'autre attrape, on polit le ballon, on nettoie, on vérifie si le ballon contient une bonne quantité d'air. Imaginez maintenant que chaque personnage s'exécute dans un thread indépendamment les uns des autres. Quelqu'un essaie d'attraper le ballon lorsqu'il n'est pas lancé. Ou quelqu'un essaie de polir la balle lorsqu'elle est jouée. Ou deux personnages essayant d'attraper et de lancer la balle simultanément. Il y a tellement de façons de planter. Les programmeurs doivent donc repenser soigneusement une application à cœur unique afin qu'elle puisse profiter de plusieurs cœurs.