pythran (compilateur orienté vers le calcul scientifique) fréquemment présenté dans ces colonnes
Un autre problème qui revient souvent (c'est affiché par la roadmap de pypy et j'en ai discuté avec le coredev de pyston) c'est la frontière en le code interprété et l'API C, qui empêche d'avoir une vue globale du code à optimiser.
un analyseur /offline/ verra a comme un int, mais à l'exécution, l'annotation pointera sur le /builtin/ float. L'expérience Pythran [0](http://pythonhosted.org/pythran] m'a convaincu que toute approche statique avec Python sera bâtarde. Pylint et consort me laissent d'ailleurs le même goût dans la bouche, « pas dans l'esprit » :-/
Pour aller dans ton sens : j'utilise de temps en temps les notebook pour faire des présentations techniques (il y a un export en slides possible) interactives, qui passent très bien suivant le public !
Super classe ! C'est une des options que j'avais envisagée (d'écrire un boost.python à la sauce c++11) mais on n'avait besoin que d'un sous ensemble… Là ça a l'air classouille !
que pythran soit exécutable avec un interpréteur python3
que le module généré par pythran soit importable en python3
que le code donné en entrée de pythran soit du python3
et toute combinaison de ces trois fonctionnalités. Pour le moment, aucune n'est supportée, on a eu assez peu de demande autour de ça, je l'avoue. Et ce n'est pas si évident car l'AST et la sémantique du langages changent entre les deux… il ne suffit pas de mettre des parenthèses dans les print ;-)
Cython n'optimise pas les appels à des fonctions numpy. Tu peux lire le fil stackoverflow dont est extrait l'exemple donné dans le journal pour voir la « meilleur solution » cython proposée et te convaincre que c'est un peu une régression :-)
il y a quelques limites liées au typage : impossible dans le modèle Pythran actuel de supporter les fonctions qui ne sont pas implicitement statiquement typées. Par exemple un truc du genre :
deffoo(n):ifn==1:return"hello"else:return5.
ensuite pour les fonctions scipy, on pourrait espérer qu'une fois le support de numpy suffisamment abouti, ça se fasse automagiquement pour celles qui ne sont pas implémentées en natif. Mais la route est encore longue, bien que certaines genre
Tu as raison ! Les choix faits par timeit nous donnent uniquement une info de type performance de crête, pas grand chose sur les effets de cache et rien sur la variabilité.
Pour le moment c'est du tout ou rien (le code de retour est le nombre d'erreurs). Si y a une erreur, tu peux te connecter à la box qui n'est détruite que si les tests ne renvoient pas d'erreur.
Tu peux aussi mettre la copie des résultats dans un shared folders, mais ça dépend des tests → pas automatique.
merci !
ma question sur le support C++ sous-entendait l'interrogation : si j'utilise du C++14 par exemple, est-ce que ça fait planter le parser / est ce que je perds des morceaux en chemin ?
Et par « quel genre de script », je pensais « quel genre d'analyse » ou « quel genre de refactoring ».
Je comprends bien que multiprocessing permet d'utiliser de la mémoire partagée, à condition d'utiliser Value ou Array (c'est ce que je comprends de la doc) mais faut copier tes données utilisateurs dans ces conteneurs, donc on a bien un transfert mémoire qu'il faut amortir, non?
De rien ;-) (Faut remercier Pierrick Brunet qui fait un boulot de ouf dessus aussi !)
Je pensais à la granularité de l'unité de calcul minimale à partir de laquelle il devient intéressant de paralléliser. En gros
a + b ** 2
où a et b sont des tableaux, ni mpi4py ni multiprocessing ne te donneront de speedup là dessus (à cause du coup de transfert mémoire) alors qu'en pure OpenMP on peut gagner (un peu sur cette exemple, mais pas beaucoup) et avec de l'AVX / SSE on gagne pas mal, suivant le type de a et b.
si on ne considère que les temps pour lesquels CPython prend plus de 1e6, parakeet est systématiquement meilleur que pythran.
Je peux même pousser l'analyse un peu plus loin : parakeet est meilleur que Pythran pour la gestion des boucles explicites. Les boucles explicites sont plutôt découragées en Numpy, car pas terrible niveau perf - c'est pour cela que tu identifies ces cas comme les cas où CPython est très lent. C'est un problème connu, sur lequel je dois m'atteler.
En fait parakeet est un très bon outil, plus facile à déployer que Pythran et avec souvent de très bonne performances. Les seuls limitations queje lui donne, c'est qu'il supporte peu de fonctions Numpy (regarde tous les 0 dans sa colonne) et qu'il ne vectorise pas les opérations - mais j'ai fais exprès de ne pas mettre ça en avant dans mes mesures.
La liste des fonctions numpy est présente coughlàcough
le support de numpy.random n'est pas problématique, pour scipy, on a une PR en cours pour que pythran compile les modules importés directement, ça devrait faire avancer la chose. mais c'est sur qu'avoir une bonne couverture de numpy/scipy, c'est un long chemin.
Astuce : quand une fonction te manque, ouvre un bug, envoie un mail sur la mliste ou poke nous sur IRC, ça motive les troupes !
J'ai peu de bagage en langages fonctionnels, mais vu les bonnes propriétés de ces derniers, y a pas de compilo qui fait de la propagation de constantes avancées pour ces langages ?
[^] # Re: Python est bien vivant
Posté par serge_sans_paille (site web personnel) . En réponse au journal MyPy 0.3 sort bien accompagné. Évalué à 5.
Et j'ajoute nombrilistiquement :
Un autre problème qui revient souvent (c'est affiché par la roadmap de pypy et j'en ai discuté avec le coredev de pyston) c'est la frontière en le code interprété et l'API C, qui empêche d'avoir une vue globale du code à optimiser.
[^] # Re: C'est intégré dans Python 3.5
Posté par serge_sans_paille (site web personnel) . En réponse au journal MyPy 0.3 sort bien accompagné. Évalué à 4.
Je trouve que ce travail autour du type hinting dans Python révèle une forme de schizophrénie assez amusante, surtout quand on lit ça dans la PEP
Le côté offline me fait un peu rire, car c'est par nature incompatible avec le côté dynamique de Python. Petit exemple tiré par les cheveux :
et son copaing
un analyseur /offline/ verra
a
comme unint
, mais à l'exécution, l'annotation pointera sur le /builtin/float
. L'expérience Pythran [0](http://pythonhosted.org/pythran] m'a convaincu que toute approche statique avec Python sera bâtarde. Pylint et consort me laissent d'ailleurs le même goût dans la bouche, « pas dans l'esprit » :-/[^] # Re: Pas beaucoups de commentaires, pourtant c'est une depeche interressante
Posté par serge_sans_paille (site web personnel) . En réponse à la dépêche Sortie de IPython/Jupyter Notebook 4.1. Évalué à 3.
Pour aller dans ton sens : j'utilise de temps en temps les notebook pour faire des présentations techniques (il y a un export en slides possible) interactives, qui passent très bien suivant le public !
Bref, super projet.
# prose très agréable !
Posté par serge_sans_paille (site web personnel) . En réponse au journal burn, cpu, burn !. Évalué à 9.
j'ai ri \o/
[^] # Re: pybind11
Posté par serge_sans_paille (site web personnel) . En réponse au journal Pythran 0.7.2 - détails techniques. Évalué à 2.
Super classe ! C'est une des options que j'avais envisagée (d'écrire un boost.python à la sauce c++11) mais on n'avait besoin que d'un sous ensemble… Là ça a l'air classouille !
# PyConFR
Posté par serge_sans_paille (site web personnel) . En réponse au journal Pythran 0.7.2 - détails techniques. Évalué à 6.
Oubli : coup de Pau, je serais à PyConFR ce week end, l'occasion de parler IRL !
[^] # Re: Python 3 ?
Posté par serge_sans_paille (site web personnel) . En réponse au journal Pythran 0.7 - PyDataParis. Évalué à 3.
Salut,
il y a plusieurs niveaux de support possible
et toute combinaison de ces trois fonctionnalités. Pour le moment, aucune n'est supportée, on a eu assez peu de demande autour de ça, je l'avoue. Et ce n'est pas si évident car l'AST et la sémantique du langages changent entre les deux… il ne suffit pas de mettre des parenthèses dans les
print
;-)# Dépêche très agréable à lire
Posté par serge_sans_paille (site web personnel) . En réponse à la dépêche Grammalecte, correcteur grammatical. Évalué à 10.
De l'informatique, de la grammaire, de la typographie, du libre, de l'humour et de la passion. Tout ça dans une seule dépêche, c'est un régal !
[^] # Re: cython
Posté par serge_sans_paille (site web personnel) . En réponse au journal Pythran 0.7 - PyDataParis. Évalué à 2.
Cython n'optimise pas les appels à des fonctions numpy. Tu peux lire le fil stackoverflow dont est extrait l'exemple donné dans le journal pour voir la « meilleur solution » cython proposée et te convaincre que c'est un peu une régression :-)
[^] # Re: Fonctions de haut niveau
Posté par serge_sans_paille (site web personnel) . En réponse au journal Pythran 0.7 - PyDataParis. Évalué à 2.
merci :-)
il y a quelques limites liées au typage : impossible dans le modèle Pythran actuel de supporter les fonctions qui ne sont pas implicitement statiquement typées. Par exemple un truc du genre :
ensuite pour les fonctions scipy, on pourrait espérer qu'une fois le support de numpy suffisamment abouti, ça se fasse automagiquement pour celles qui ne sont pas implémentées en natif. Mais la route est encore longue, bien que certaines genre
https://github.com/scipy/scipy/blob/v0.15.1/scipy/optimize/optimize.py#L154
passeraient sans soucis.
[^] # Re: micro bench dans une loupe
Posté par serge_sans_paille (site web personnel) . En réponse au journal Pythran 0.7 - PyDataParis. Évalué à 3.
Tu as raison ! Les choix faits par
timeit
nous donnent uniquement une info de type performance de crête, pas grand chose sur les effets de cache et rien sur la variabilité.[^] # Re: Rapatrier le résultat
Posté par serge_sans_paille (site web personnel) . En réponse au journal Automatiser les tests multi-plateforme avec Sivart. Évalué à 1.
Pour le moment c'est du tout ou rien (le code de retour est le nombre d'erreurs). Si y a une erreur, tu peux te connecter à la box qui n'est détruite que si les tests ne renvoient pas d'erreur.
Tu peux aussi mettre la copie des résultats dans un shared folders, mais ça dépend des tests → pas automatique.
Des idées ?
[^] # Re: Des détails !
Posté par serge_sans_paille (site web personnel) . En réponse à la dépêche Sortie de vera++ 1.3.0. Évalué à 1.
merci !
ma question sur le support C++ sous-entendait l'interrogation : si j'utilise du C++14 par exemple, est-ce que ça fait planter le parser / est ce que je perds des morceaux en chemin ?
Et par « quel genre de script », je pensais « quel genre d'analyse » ou « quel genre de refactoring ».
Désolé pour la mauvaise formulation !
# Des détails !
Posté par serge_sans_paille (site web personnel) . En réponse à la dépêche Sortie de vera++ 1.3.0. Évalué à 8.
Salut !
Le minimalisme de l'annonce m'a poussé à jeter un œil aux sources, et là plein de questions :
boost::wave
? Ça parse / comprend tout ?clang-format
, ça donne quoi ?merci !
[^] # Re: une solution
Posté par serge_sans_paille (site web personnel) . En réponse au message intel intrinsics. Évalué à 2.
Je suis curieux : vu la granularité de la boucle, OpenMP te donne des gains ?
[^] # Re: Support de Numpy
Posté par serge_sans_paille (site web personnel) . En réponse à la dépêche Pythran 0.6 - compilation de noyaux scientifiques écrits en Python. Évalué à 1.
Intéressant !
On s'éloigne sensiblement de la clarté d'un code Python d e haut niveau, mais l'astuce est bonne à prendre, merci ;-)
[^] # Re: Support de Numpy
Posté par serge_sans_paille (site web personnel) . En réponse à la dépêche Pythran 0.6 - compilation de noyaux scientifiques écrits en Python. Évalué à 1.
Je comprends bien que
multiprocessing
permet d'utiliser de la mémoire partagée, à condition d'utiliserValue
ouArray
(c'est ce que je comprends de la doc) mais faut copier tes données utilisateurs dans ces conteneurs, donc on a bien un transfert mémoire qu'il faut amortir, non?[^] # Re: Support de Numpy
Posté par serge_sans_paille (site web personnel) . En réponse à la dépêche Pythran 0.6 - compilation de noyaux scientifiques écrits en Python. Évalué à 1.
De rien ;-) (Faut remercier Pierrick Brunet qui fait un boulot de ouf dessus aussi !)
Je pensais à la granularité de l'unité de calcul minimale à partir de laquelle il devient intéressant de paralléliser. En gros
où a et b sont des tableaux, ni
mpi4py
nimultiprocessing
ne te donneront de speedup là dessus (à cause du coup de transfert mémoire) alors qu'en pure OpenMP on peut gagner (un peu sur cette exemple, mais pas beaucoup) et avec de l'AVX / SSE on gagne pas mal, suivant le type dea
etb
.Je ne sais pas si mes explications sont claires…
[^] # Re: Support de Numpy
Posté par serge_sans_paille (site web personnel) . En réponse à la dépêche Pythran 0.6 - compilation de noyaux scientifiques écrits en Python. Évalué à 1.
Certes, mais avec une granularité toute autre.
[^] # Re: Parakeet winner?
Posté par serge_sans_paille (site web personnel) . En réponse à la dépêche Pythran 0.6 - compilation de noyaux scientifiques écrits en Python. Évalué à 2.
Je peux même pousser l'analyse un peu plus loin : parakeet est meilleur que Pythran pour la gestion des boucles explicites. Les boucles explicites sont plutôt découragées en Numpy, car pas terrible niveau perf - c'est pour cela que tu identifies ces cas comme les cas où CPython est très lent. C'est un problème connu, sur lequel je dois m'atteler.
En fait parakeet est un très bon outil, plus facile à déployer que Pythran et avec souvent de très bonne performances. Les seuls limitations queje lui donne, c'est qu'il supporte peu de fonctions Numpy (regarde tous les 0 dans sa colonne) et qu'il ne vectorise pas les opérations - mais j'ai fais exprès de ne pas mettre ça en avant dans mes mesures.
Un concurrent sérieux donc ;-)
[^] # Re: Le même en Fortran SVP
Posté par serge_sans_paille (site web personnel) . En réponse à la dépêche Pythran 0.6 - compilation de noyaux scientifiques écrits en Python. Évalué à 3.
Mon FORTRAN est un peu rouillé. Comment se porte le tien ? ;-)
[^] # Re: Support de Numpy
Posté par serge_sans_paille (site web personnel) . En réponse à la dépêche Pythran 0.6 - compilation de noyaux scientifiques écrits en Python. Évalué à 4.
Content que ça te plaise \o/
La liste des fonctions numpy est présente cough là cough
le support de
numpy.random
n'est pas problématique, pour scipy, on a une PR en cours pour que pythran compile les modules importés directement, ça devrait faire avancer la chose. mais c'est sur qu'avoir une bonne couverture de numpy/scipy, c'est un long chemin.Astuce : quand une fonction te manque, ouvre un bug, envoie un mail sur la mliste ou poke nous sur IRC, ça motive les troupes !
# POD vs PDO
Posté par serge_sans_paille (site web personnel) . En réponse au journal Veuillez instancier ce journal avant de le lire. Évalué à 3.
Commentaire inutile et donc indispensable, on parle plutôt de Plain_old_data_structure donc POD que de PDO :-)
[^] # Re: Plutôt beauté du design
Posté par serge_sans_paille (site web personnel) . En réponse au journal "beauté du code". Évalué à 2.
J'ai peu de bagage en langages fonctionnels, mais vu les bonnes propriétés de ces derniers, y a pas de compilo qui fait de la propagation de constantes avancées pour ces langages ?
[^] # Re: Plutôt beauté du design
Posté par serge_sans_paille (site web personnel) . En réponse au journal "beauté du code". Évalué à 1.
En fait ce que tu veux c'est une forme de propagation de constantes interprocédurales, non ?
<pub>
Pythran le fait dans certains cas</pub>
Par exemple :
est transformé (à la compilation) en