Salut les réptiles,
Pythran est un compilateur Python vers C++ ciblé pour le calcul scientifique, dont je vous ai déjà parlé à de nombreuses reprises.
À la fin de l'épisode précedent, je partais pour les US et présenter mon bébé au monde entier. Voici donc mon carnet de notes virtuels.
Déjà il faut répéter ses présentations, sinon ça donne ça, où l'on voit que je ferais bien d'apprendre à me tenir droit…
Ensuite j'ai eu quelques retours intéressants, des gens ont essayé l'outil, ça a même gazouillé un peu sur le projet, et comme je ne suis pas un grand agitateur de foule, c'est bien que d'autres le fassent.
Le truc important, c'est que ça a donné naissance à un projet de micro-benchmarks sur le python scientifique, codé par l'agréable Olivier Grisel que j'ai découvert pour l'occasion (un classique : il faut sortir de France pour rencontrer des français ;-) ) : python-benchmarks
Il me semble que pour le domaine ciblé, la notion de micro-bench est assez valide (on passe souvent beaucoup de temps dans quelques lignes de code dans le monde où j'évolue), et quand on regarde les résultats on voit que notre modeste équipe s'en sort plutôt bien [*] par rapport aux ténors du milieu.
Ça m'a aussi permis de consolider ma culture en accélération de python scientifique, les individus à l'esprit tortueux semblant aimer theano (vous vivez dans un monde peuplé de tenseurs vous ?) et la concurrence directe de parakeet qui se limite au strict nécessaire pour faire du numpy, mais qui le fait bien et est porté par le très Alex Rubinsteyn souriant.
En suivant le très agréable didacticiel cython, je me suis dis que l'expérience utilisateur était assez proche de celle de Pythran, une bonne chose a priori.
[*] franchement, vous avez vu comment on écrase bien tout le monde, mouarf mouarf mouarf
# idée pour les prochaines presentations
Posté par NeoX . Évalué à 4.
Evidemment repeter, repeter, afin de super bien connaitre ta presentation pour ne plus avoir qu'a "lire" ce qui est projeté pour savoir ou tu en es.
Bon, je critique, mais avec le decalage horaire ca doit quand meme pas etre simple,
et je trouve ca deja bien d'aller presenter ton bébé à la communauté.
# En anglais?
Posté par Zenitram (site web personnel) . Évalué à -2. Dernière modification le 15 juillet 2013 à 17:40.
Toi, à parler au monde entier en anglais, tu veux te faire des amis! ;-)
(bon, sinon je suis rassuré, je ne suis pas le seul avec un accent qui tue, désolé :) )
# Theano
Posté par neil . Évalué à 5. Dernière modification le 15 juillet 2013 à 19:52.
Sachant que les tenseurs sont des tableaux multi-dimensionnels, avec tout un tas d’opérations bien définies dessus, et vu que la bibliothèque (ultra-lente mais) de facto standard pour faire du calcul scientifique sous Python est NumPy, basée sur des tableaux multi-dimensionnels, il me semble que oui, une énorme partie des applications scientifiques sous Python vivent dans un monde de tenseurs. Ne serait-ce qu’en raison de la facilité pour les opérations tensorielles à être implémentés de façon rapide voire parallèle.
En plus de la génération transparente de code pour GPU, Theano est aussi capable de générer du code C de façon dynamique. Vu que c’est aussi ce que fait Pythran (module le ++), comment est-ce que les algorithmes et technologies de ces générations de code se comparent ?
Theano se compare aussi à des bibliothèques écrites dans d’autres langages (comme Torch en LuaJIT ou RNNLM en C++). Il est d’ailleurs sympa de constater que même sans activer le support des SMP ou des GPU, Theano est plus rapide que la version C++ de RNNLM. Est-ce que des comparaisons du même ordre sont envisagées pour Pythran, histoire de ne pas comparer des pommes et des bananes (unique processeur VS SMP, ni code C++ généré VS code pur Python) ?
[^] # Re: Theano
Posté par marsup . Évalué à 1.
J'ai une petite question : tu dis que numpy est lent, mais j'avais compris le contraire en furetant sur le web. J'avais lu en particulier que les opérations étaient très rapides, car le plus souvent basées sur des appels BLAS…
[^] # Re: Theano
Posté par neil . Évalué à 1. Dernière modification le 16 juillet 2013 à 18:06.
NumPy est rapide pour certaines opérations déjà optimisées dans BLAS et encodées en dur dans la bibliothèque, mais est assez lent pour tout le reste, y compris des choses basiques comme les convolutions. Rien que le fait que ce soit du pur Python (à l’utilisation, pas la bibliothèque en elle-même qui est en C) est déjà lent, il y a l’évaluation paresseuse qui manque (quand on écrit
b + c + dil fait une copie mémoire pourb + c, puis encore une opération et une allocation pour le+ d). Ensuite il y a le problème du parallélisme qui n’est pas géré (mais c’est général en Python).L’avantage des bibliothèques comme Pythran (et comme le dit serge_paille en dessous), c’est de passer par une étape intermédiaire qui va appliquer tout un tas d’optimisations avant l’exécution (la liste en dessous pour Pythran est impressionnante : AVX, OpenMP, évaluation paresseuse [dans un autre sens], constant folding, …). L’un des gros avantages de Pythran c’est d’être compatible avec NumPy, ce qui est top pour pouvoir développer et partager du code rapidement (sous-entendu, par copier/coller, ce qui est l’outil fondamental des langages non-typés :p), et permet d’avoir une courbe d’apprentissage douce. En gros ça rajoute une partie de l’étape « compilation » qui manque à un langage de script.
[^] # Re: Theano
Posté par serge_sans_paille (site web personnel) . Évalué à 3.
Merci pour cette réponse très intéressante. Je vais essayer de me justifier :
Tout d'abord je n'ai rien contre Theano, au contraire, je trouve que c'est un DSL très intéressant, avec de belles idées derrières. La remarque sur le monde de tenseur attaquait plutôt le côté DSL justement, Theano ne permet pas d'exprimer des algos à base de dictionnaire, ensembles etc. Il fallait donc prendre ma petite pique dans ce sens là.
Vu ce côté DSL, on peut en effet s'attendre à de très bonne perfs, surtout vu le passif existant dans le domaine pour l'algèbre linéaire.
Pour les technos, Pythran génère statiquement du C++, éventuellement parallèle si le parallélisme a été décrit de façon explicite (à l'aide de directives OpenMP) ou s'il est implicite (opérations numpy principalement). Il est capable, mais c'est expérimental, de généré des instructions AVX. Le benchmark n'utilise pas cette possibilité. De plus il effectue un certain nombre d'optimisations spécifiques à Python comme la traduction de listes en générateurs (évaluation paresseuse) quand c'est légal, ou l'évaluation interprocédurale à la compilation de code indépendant du contexte (a.k.a. constant folding).
Pour ce qui est des performances, je ne suis pas celui qui fait tourner les benchs ni celui qui contrôle l'environnement, donc je ne peux pas te donner de détail (mais considérons que c'est plutôt gage impartialité), mais la lecture des liens ci dessus, en particulier http://numfocus.github.io/python-benchmarks/#results-arc_distance , http://numfocus.github.io/python-benchmarks/#results-pairwise et http://numfocus.github.io/python-benchmarks/#results-rosen_der montre que pythran tient bien le choc de la confrontation, tout en restant compatible avec numpy alors que theano demande une réécriture complète du code.
Donc non je ne me compare pas que à Python ou numpy, mais au contraire à pleins de compilos qui génèrent du code natifs. Donc pas de pommes et de bananes, mais des pommes de différents variétés (hop, je prends la variété reinette d'armorique, excellente en tarte et crumble).
# Et hors de Python?
Posté par Maclag . Évalué à 4.
Tu es bien modeste sur les résultats de Pythran face aux solutions alternatives. Pour ceux qui ne cliquent pas, par "s'en sort bien", il veut dire que suivant les tests, soit Pythran n'est pas loin des meilleurs, ou soit il leur met une méchante raclée.
Par contre, ces microbenchmarks ne semblent pas concerner autre chose que des solutions Python. Et c'est là que je demande: pourquoi?
Parce que si je suis utilisateur final qui a besoin d'une solution performante, apprendre un peu de R (assez facile à appréhender vu de ma fenêtre), un peu de C (bon, là, clairement moins, mais je le ferais quand même) ou autre, ce ne sera pas un facteur rebutant.
Est-ce que utiliser Python à tout prix fait partie du cahier des charges, ou est-ce parce que les alternatives ne sont pas tellement meilleures? (Je pense à R en particulier, surtout que ça s'interface avec à peu près tous les autres langages, mais on pourrait facilement allonger la liste).
[^] # Re: Et hors de Python?
Posté par serge_sans_paille (site web personnel) . Évalué à 2.
Salut,
Je ne comprends pas bien ta question : j'ai choisi le langage Python comme langage d'entrée car c'est un langage qui a une communauté scientifique assez forte, et que j'utilise (comme ça je suis aussi utilisateur de mon outil, ce qui me garanti d'avoir au moins un utilisateur ;-) ). Je ne connais rien à R mis à part que c'est utilisé par des statisticiens.
Comme c'est un projet perso, pas de cahier des charges, mais si tu as pleins de sous et ne sais qu'en faire, je cherche du boulot pour octobre ;-)
[^] # Re: Et hors de Python?
Posté par Maclag . Évalué à 3.
Ah mais c'est une excellente raison, et ça rentre tout-à-fait dans un "cahier des charges" de projet perso: c'est pour ton usage, tu te sers de Python, il est naturel que tu développes pour Python.
(Je considère que tous les projets perso ont un cahier des charges, même non écrit. C'est simplement la description de ce que tu veux faire!)
Je ne remettrais certainement pas en cause les choix que tu fais sur tes projets (surtout qu'y a pas longtemps j'ai fait une interface en tk, et pourquoi tk? ben parce que je n'ai pas cherché plus loin que le binding intégré…)
Ce que je me demandais, c'est pourquoi les micro-benchmarks ne contiennent que des solutions Python (en dehors de l'évidence: parce que c'est un évènement Python). Je suppose que c'est fait moins souvent, mais de temps en temps, il doit bien y avoir comparaison avec des solutions non-Python, non?
Et sinon, non, je suis au regret de te dire que je ne suis pas employeur, et en fait même pas dans une branche info.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.