serge_sans_paille a écrit 269 commentaires

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.

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.

Un concurrent sérieux donc ;-)

Mon FORTRAN est un peu rouillé. Comment se porte le tien ? ;-)

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 !

Commentaire inutile et donc indispensable, on parle plutôt de Plain_old_data_structure donc POD que de PDO :-)

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 ?

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 :

def fib(n):
 return n if n < 2 else (fib(n - 1) + fib(n - 2))
def foo(): print map(fib, [1,2,3])

est transformé (à la compilation) en

 def fib(n):
 return (n if (n < 2) else (fib((n - 1)) + fib((n - 2))))
 def foo():
 print [1, 1, 2]

et les constexpr ? mmh ?

Un peu d'ouverture d'esprit, je te prie.

Une pâquerette, certains trouvent ça beau, d'autres trouvent ça moche. Rien à voir avec des critères objectifs. Allez je vais te citer un extrait de http://rue89.nouvelobs.com/2014/09/27/geek-sublime-code-cest-emotionnel-254952

N’est-ce pas un peu abusif de la part des codeurs de se revendiquer artistes – juste une façon pour eux de gagner un prestige qu’ils ne méritent pas vraiment ?

Je suis d’accord avec vous ! C’est une méprise sur la nature de l’art et du travail d’artiste. Les programmeurs ont tendance à croire énormément en la rationalité : « Quoi qu’il arrive dans le monde, je peux le comprendre. » Du coup, face à la question « comment être un artiste ? », ils se disent : « Bon, si je réfléchis là-dessus un petit moment, je vais pouvoir moi aussi être un artiste. » [Rires.]

Si, quand vous touchez quelque chose, tout le reste du code se met à vibrer de partout, alors vous savez que c’est vraiment laid

Cette phrase a fait resurgir en moi des souvenirs de thèse que j'aurais aimé oublier :-)

Je trouve que s/beau/maintenable/ serait plus exact, on peut trouver certaines constructions élégantes alors qu'elles ne sont pas pour autant maintenables...

pour le 2), c'est du linux, il me semble.

Si tu penses à backtrace() de execinfo.h oui :-)

cf. http://stackoverflow.com/questions/3355683/c-stack-trace-from-unhandled-exception

Est-ce que par hasard tu connais des outils qui vont un pas plus loin et font du parallélisme distribué? Par exemple qui récupère une liste de comptes SSH et lance des programmes sur l'hôte distant?

http://taktuk.gforge.inria.fr/

Est-ce que tu as comparé avec Cython

Parfois, et c'est très variable. Déjà Cython demande de bien connaître Cython, ce qui n'est pas le cas pour numba/parakeet/pythran. Donc si je me compare à un programme Cython, je mesure surtout mon degré de maîtrise de Cython et de ses annotations. Et il me semble que le système de typage de Cython est déclaratif : tu décris les types et il génère le code, alors que numba/parakeet/pythran infèrent les types.

J'essaierai de faire un tour :)

Paradise yeah !

jusqu'à ce que je corrige le bug de performance

mauvais lien, il fallait lire la branche fix-complex