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).
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).
[^] # Re: Theano
Posté par serge_sans_paille (site web personnel) . En réponse au journal Pythran revient de SciPy2013. É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).