serge_sans_paille a écrit 261 commentaires

Quand je lis la doc du projet, je ne vois aucune mention de typage statique, ça me fait plutôt penser à l'approche de Nuitka qui transforme n'importe quel code Python en programme C++ qui appelle le runtime CPython. Là ils ont ré-implem le runtime CPython il me semble, mais l'idée est la même.

D'une certaine façon, ça ressemble aussi à Pyston avec le JIT en moins.

Assez loin de Pythran finalement, puisqu'ils visent une approche générique, pas un embeded Domain Specifc Language, un langage spécialisé pour le calcul scientifique embarqué dans Python.

Sinon le fait de se concentrer sur Python2.7 (même choix que Pyston !) est discutable. On a mis plusieurs mois à supporter Python3 dans Pythran après avoir fait ce choix, je les plains :-)

La version cython utilise-t-elle le SIMD ?

Elle est compilée avec des drapeaux qui permettent la vectorisation, mais après avoir inspecté le binaire, gcc a pas réussi à vectoriser, non. Du coup ça veut dire que la version pythran a encore un soucis, mais je n'ai pas encore trouvé lequel :-)

car j'avais vraiment besoin de classes

C'est dans ma TODO liste, tiens tu attendrais quoi comme annotation #pythran export pour une classe ? C'est pas bien fixé pour moi…

Il y a un état de fai[tl] : la demande est là. Il suffit de regarder les compilos existants :

• cython
• numba
• pyston
• pypy

Et chacun de ces compilos a pour objectif principal ou auxiliaire mais en tout cas affiché d'optimiser du code Python utilisant numpy :-)

Oui, c'est le leïtmotiv de Pythran : obtenir les performances d'un code compilé (pour ce que ça peut vouloir dire) et optimisé, sans avoir à descendre le niveau d'abstraction.

CPython pur :

> rm *.so
> python -m perf timeit -s 'from scipy.stats import ortho_group; from perm import npperm ; import numpy as np; np.random.seed(7);M = ortho_group.rvs(23)' 'npperm(M)'
.....................
Median +- std dev: 20.4 sec +- 1.1 sec

c'est ultra lent :-)

using force = long/*evity*/;

using the = force;

the jedi(char acter[] = "luke" ) {
  return 0.f + the(&jedi);
}

sous CC BY-SA 4

c’est f() avant g() (sequenced before).

Je pense que c'est c’est f() avant h() (sequenced before)

Sinon excellent journal, le dessin m'a bien fait marrer !

Passionnant ! Merci !

1/ Ne jamais réinventer des hashes (sans une très bonne raison),

Tout à fait d'accord avec toi; C'est même écrit dans le journal :-/

[…] on aurait pu éviter de fournir une implem miteuse

ou simplement mettre les strings dans une hash table (clef) et mettre une fonction en valeur
il n'y a pas qu'une seule solution

Tout à fait d'accord avec toi; C'est même écrit dans le journal :-/

Et pour les chagrins qui veulent du code dans leur case: on peut utiliser une std::function

Avec un code qui illustre ça

Je pense que c'est aussi un problème d'API, ou plutôt de compromis API/perf.

Prenons le cas de GMP, il est chouette. Tu as trois entiers multi-précision a b et c. Tu veux calculer rapidement a + b * c. Tu peux demander à l'utilisateur d'écrire (et ce le cas en C d'ailleurs), mpz_mul(tmp, b, c); mpz_add(out, a, tmp). Le problème c'est que (en plus d'être verbeux) tu introduis un temporaire, et que peut-être qu'il existe une façon de faire un fused multiply add plus efficacement qu'en le cassant en une multiplication et une addition, comme pour la boucle que tu cites où la fusion de boucle a permis, entre autres, de ne pas parcourir deux fois les tableaux. Et tu ne peux pas te permettre d'écrire toutes les fonction add_muladd_add_mul` etc pour chaque optimisation possible.

Les expression templates en général permettent de résoudre les deux soucis : au niveau API, l'utilisateur écris juste a + b * c et au niveau perf la machinerie (souvent bien plus complexe que ce qui est présentée ici, et bien mieux faite aussi) se charge de l'évaluation efficace de l'expression.

Et tu as raison, l'évaluation paresseuse fait parti des effets de bord sympa ;-)

Et j'ajoute nombrilistiquement :

• 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.

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

Instead, it is assumed that a separate off-line type checker (e.g. mypy) will be used for on-demand source code analysis.

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 :

file1.py

import builtins 
builtins.int= float
import file2

et son copaing

def foo(a: int):
    return a

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 !

Bref, super projet.

La température du dissipateur redescend (mon petit doigt me dit, pour une fois il est assez fiable, là)

j'ai ri \o/

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 !

Oubli : coup de Pau, je serais à PyConFR ce week end, l'occasion de parler IRL !

Salut,

il y a plusieurs niveaux de support possible

1. que pythran soit exécutable avec un interpréteur python3
2. que le module généré par pythran soit importable en python3
3. 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 ;-)

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 !

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 :-)

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 :

def foo(n):
  if n == 1: return "hello"
  else: return 5.

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.

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.

Des idées ?

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 ^!

Salut !

Le minimalisme de l'annonce m'a poussé à jeter un œil aux sources, et là plein de questions :

• vous avez développé un parseur C++ en boost::wave ? Ça parse / comprend tout ?
• par rapport à clang-format, ça donne quoi ?
• quel genre de script sont utilisés ?

merci !

Je suis curieux : vu la granularité de la boucle, OpenMP te donne des gains ?