Grumpy ne va pas deux fois plus vite que CPython. Sur un benchmark probablement pourri (vu le nom "fib", on peut supposer que c'est un calcul de la suite de Fibonacci),
Oui, c'est un benchmark classique pour évaluer l'overhead de création de threads/processus pour une application parallèle. Le code « classique » est le suivant :
/* J'utilise OpenMP pour paralléliser parce que je suis paresseux */longfib(longn){longn1=0,n2=1;if(n<2)returnn;# pragma omp task shared(n1) firstprivate(n)n1=fib(n-1);# pragma omp task shared(n2) firstprivate(n)n2=fib(n-2);# pragma omp taskwaitreturnn1+n2;}
À noter que la performance parallèle de ce code est abominable, et qu'une bonne implémentation séquentielle et impérative ira 100 fois plus vite (littéralement).
Mais ce code permet d'évaluer la robustesse du runtime/système quand on crée des tâches de façon exponentielle, car il n'y a pratiquement pas de calcul à effectuer. C'est un benchmark classique dans le domaine de l'évaluation de création de tâches. Cependant, je connais aussi pas mal de gens qui n'aiment pas ce benchmark, car il n'est pas forcément représentatif de vrais workloads utilisés pour des applications parallèles, et fait l'impasse sur certaines optimisations qui existent dans les environnement d'exécution qui proposent un système de création de threads/tâches et qui tirent parti de tout un tas d'aspects architecturaux.
Mais là n'était pas mon propos. Je n'ai pas analysé la pertinence de ce benchmark dans mon post précédent. Juste que, lorsqu'on publie un graphique pareil, généralement ce n'est pas anodin, et qu'on estime que ça va permettre d'avoir des performances pas obtenues par ailleurs.
Grumpy est deux fois plus lent en simple thread que CPython, et ne parvient à devenir plus rapide qu'en utilisant plus de cœurs...
C'est relativement classique dans l'implémentation de runtimes pour favoriser les threads : l'avantage ne commence à se voir que lorsqu'on les exécute sur de grands nombres de processeurs/threads matériels.
(note : ne pas confondre CPython - l'implémentation principale de Python, écrite en C - et Cython - un compilateur statique de Python vers C)
Oups ! Oui tu as complètement raison, j'ai lu vite et mon cerveau a (mal) interpolé.
[^] # Re: logique pour Google
Posté par lasher . En réponse au journal Grumpy : un nouveau concurrent à pythran. Évalué à 4.
Oui, c'est un benchmark classique pour évaluer l'overhead de création de threads/processus pour une application parallèle. Le code « classique » est le suivant :
À noter que la performance parallèle de ce code est abominable, et qu'une bonne implémentation séquentielle et impérative ira 100 fois plus vite (littéralement).
Mais ce code permet d'évaluer la robustesse du runtime/système quand on crée des tâches de façon exponentielle, car il n'y a pratiquement pas de calcul à effectuer. C'est un benchmark classique dans le domaine de l'évaluation de création de tâches. Cependant, je connais aussi pas mal de gens qui n'aiment pas ce benchmark, car il n'est pas forcément représentatif de vrais workloads utilisés pour des applications parallèles, et fait l'impasse sur certaines optimisations qui existent dans les environnement d'exécution qui proposent un système de création de threads/tâches et qui tirent parti de tout un tas d'aspects architecturaux.
Mais là n'était pas mon propos. Je n'ai pas analysé la pertinence de ce benchmark dans mon post précédent. Juste que, lorsqu'on publie un graphique pareil, généralement ce n'est pas anodin, et qu'on estime que ça va permettre d'avoir des performances pas obtenues par ailleurs.
C'est relativement classique dans l'implémentation de runtimes pour favoriser les threads : l'avantage ne commence à se voir que lorsqu'on les exécute sur de grands nombres de processeurs/threads matériels.
Oups ! Oui tu as complètement raison, j'ai lu vite et mon cerveau a (mal) interpolé.