Je vois plusieurs problème potentiels avec ce code :
le test dépend de requêtes HTTP externes, ce qui introduit certainement beaucoup de variabilité, potentiellement plus grande que celle entre threads et green threads
la méthode pour faire ces requêtes n'est pas la même
tu ne mesures pas vraiment green thread vs thread système, mais asyncio vs threads systèmes en Python. Bon, pas le choix que de tester des implems existantes, mais peut-être que l'asynchrone Python n'est pas très performant par exemple, alors que peut-être que ce n'est pas une limite théorique des green threads (je ne connais pas très bien les green threads ni asyncio cela dit)
de ce que je comprends du code, tu ne lisses pas les résultats en exécutant plusieurs fois les tests, dans des ordres différents (tu risques de "chauffer" et donc favoriser le deuxième test en exécutant le premier d'une manière ou d'une autre, donc il est important d'alterner les tests)
Cela dit, ton résultat ne m'étonne pas : je m'attends à ce qu'un processus parallélisable s'exécute plus vite sur plusieurs threads systèmes que sur plusieurs green threads placés sur un seul thread système : il n'y a pas de parallélisme dans ce cas ! :-) Et c'est probablement ce que fait ressortir ton test.
Les vraies questions à mon avis seraient plutôt :
est-ce que si on implémente intelligemment les green threads sur plusieurs threads systèmes (éventuellement, en fixant ces threads sur des cœurs), on peut gagner en perf (en utilisant X green threads sur N cœurs versus X threads systèmes sur N cœurs) ?
est-ce que pour un ensemble de tâches non parallélisables / non parallélisées, on arrive à une meilleure perf avec plusieurs plusieurs green threads sur un seul thread système versus plusieurs threads systèmes sur un seul cœur ?
j'imagine que Barmic à plus ça en tête. Effectivement, il est possible que le "switch" soit plus léger au moins dans ce deuxième cas, voire dans le premier si c'est bien gérer (mais le risque dans le premier cas c'est de se payer aussi les context switch des threads systèmes en plus de entre les green threads si c'est mal géré...).
[^] # Re: Des bonnes idées
Posté par raphj (site web personnel) . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 2. Dernière modification le 06 décembre 2020 à 19:04.
Je vois plusieurs problème potentiels avec ce code :
Cela dit, ton résultat ne m'étonne pas : je m'attends à ce qu'un processus parallélisable s'exécute plus vite sur plusieurs threads systèmes que sur plusieurs green threads placés sur un seul thread système : il n'y a pas de parallélisme dans ce cas ! :-) Et c'est probablement ce que fait ressortir ton test.
Les vraies questions à mon avis seraient plutôt :
j'imagine que Barmic à plus ça en tête. Effectivement, il est possible que le "switch" soit plus léger au moins dans ce deuxième cas, voire dans le premier si c'est bien gérer (mais le risque dans le premier cas c'est de se payer aussi les context switch des threads systèmes en plus de entre les green threads si c'est mal géré...).