serge_sans_paille a écrit 257 commentaires

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 ?

Intéressant !
On s'éloigne sensiblement de la clarté d'un code Python d e haut niveau, mais l'astuce est bonne à prendre, merci ;-)

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.

Je ne sais pas si mes explications sont claires…

Certes, mais avec une granularité toute autre.