Qui a dit que c'était impossible ? Extrêmement difficile. N'offrant pas nécessairement les avantages escomptés. D'un coût prohibitif. Mais impossible. Non, ce n'est pas impossible.
Ce serait possible avec une seule application logicielle ? Oui, si vous êtes prêt à dépenser quelque chose de l'ordre d'un milliard de dollars pour construire une telle appli et à attendre probablement cinq ans pour qu'elle soit utilisable, et elle serait probablement encore boguée et capricieuse.
C'est déjà assez difficile pour les humains d'écrire des apps multithreads. Automatiser le processus est beaucoup plus difficile.
Laissez-moi vous donner un exemple concret. Une de mes dernières tâches chez Intel était de convertir une partie de cet outil d'expression régulière appelé Hyperscan pour faire certaines choses en multithread. Maintenant, les expressions régulières sont un type de programme assez bien connu et contenu. Vous pouvez écrire un simple interpréteur d'expressions régulières en tant qu'étudiant de premier cycle. Un vraiment simple pourrait même être simplement un devoir à la maison.
De plus, la théorie est bien établie et une partie d'hyperscan a converti des NFAs en DFAs en utilisant l'algorithme standard. Mais les DFAs sont monofilaires et souffrent d'une explosion combinatoire. Donc, hyperscan a des stratégies de secours si la conversion ne fonctionne pas, comme l'exécution d'un NFA. Mais l'exécution d'un DFA est plus efficace lorsque la conversion fonctionne. Donc, ma tâche était de transformer le NFA en plusieurs DFA (jusqu'à un maximum de huit) et ensuite d'essayer d'exécuter ces DFA en parallèle.
Étape 1, j'ai réécrit le moteur de DFA de sorte que si l'explosion combinatoire s'installe, il arrête de construire le DFA actuel et passe à la construction d'un nouveau. N'abandonnant que s'il en avait déjà construit huit.
Étape 2, exécution des DFA en parallèle comme s'il s'agissait de threads, mais en lock-step.
Étape 3, remaniement des DFA pour qu'ils soient entrelacés et fassent autant de travail en parallèle que possible.
J'ai écrit ailleurs sur l'étape 3. Cependant, aucune de ces tâches n'était entièrement triviale et ce, malgré le fait qu'il s'agissait essentiellement de choses à faire dans les manuels scolaires. Le projet a pris environ six mois avant que nous ayons quelque chose qui fonctionne suffisamment bien pour que le résultat soit meilleur que la simple exécution de la NFA originale et vaille la peine d'être expédié. Bien sûr, à ce moment-là, quand cela a fonctionné, cela nous a permis d'obtenir une amélioration substantielle des performances et cela nous a permis de remporter une victoire de conception chez le client spécifique que nous ciblions.
Donc, voici le multithreading d'une application - et pas toute l'application juste une partie spécifique de celle-ci, où la partie que nous multithreadions avait de belles propriétés simples et vous parlez encore de mois d'une personne qui connaît ce domaine d'application à fond.
Comparer cela à la quantité d'effort qui va dans des choses comme les émulateurs pour une puce sur une autre. Ces projets sont des projets de plusieurs années et de plusieurs personnes. Ils ne font pas de multithreading, ils essaient juste de s'assurer que la sémantique d'une puce est fidèlement recréée sur une autre puce. Ou des choses comme VMware, qui ne font même pas tout le jeu d'instructions, juste un petit sous-ensemble et pourtant des sociétés entières se sont formées autour de cette idée. Ou des compilateurs juste à temps pour les JVM.
Toutes ces choses sont grandes, et essayer de restructurer un programme à un seul thread en un programme multithread est tout aussi grand que n'importe laquelle de ces choses.
Ce n'est pas pour tout de suite. Ce ne sera certainement pas quelque chose quand cela se produira que vous pouvez plonger 50 $ et obtenir un accélérateur de jeu.
Il n'y a pas d'autre solution.