serge_sans_paille a écrit 258 commentaires

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

Salut Antoine,

super dépêche. J'ai A.D.O.R.É la lecture du document d'architecture de Numba, il est très clair et donne plein d'indices pour comprendre le comportement interne et avoir une idée de la qualité du code généré. Chapeau !

Tu as écris :

Il est également capable d'optimiser les appels à des fonctions externes via ctypes ou cffi.

C'est alléchant ! ça veut dire que vous « comprenez » l'API de ctypes et que vous arrivez à linker avec la lib native directement ?

Que serait une dépêche sur Numba sans une comparaison avec des challenges un peu plus costaud que CPython !

Très similaire à Numba (aussi un JIT), on trouve parakeet. Parakeet est plus spécialisé que Numba (par exemple il ne gère pas la construction avec un break et un else), mais il arrive à optimiser les appels de (quelques) fonctions numpy, et les parallélise automatiquement. L'auteur est très souriant et a fait une présentation intéressante à Pydata 2013.

En approche statique, il y a l'ineffable pythran qui tient la dragée haute à Numba, même s'il ne propose pas de mode dégradé et ne propose pas de backend CUDA. Et l'approche statique est plus lourde à mettre en œuvre qu'un décorateur. Sur l'exemple de mandelbrot, il va… moins vite que Numba. Enfin il allait moins vite jusqu'à ce que je corrige le bug de performance. La beauté du libre et de l'émulation. Son très sympathique et très modeste auteur a fait une présentation généraliste et passera bientôt à Paris !

Numpypy est encore un peu jeune, mais devrait permettre à PyPy de passer la frontière de l'API native imposée par Numpy…

On avance, on avance on avance, c'est une évidence… (air connu)

ce qui est toujours mieux que

Rame, rame rameurs, ramez

Plus sérieusement, on a quelques utilisateurs réguliers de part le monde (au moins un en France, un en Grande Bretagne et un aux US) qui remontent des bugs de temps en temps. D'après pypi on aurait plus que ça, mais c'est dur de savoir vraiment. Et quelques vues sur github.

On a encore pleins d'idées à implémenter, on essaie de faire de la bonne ingénierie, et on manque de temps… mais on s'amuse bien (on = 3 devs réguliers).

Le code a très probablement été adapté du Matlab ou du FORTRAN qui sont en column major alors que C/C++ sont en row major. Dans le cas présent, à chaque fois que la boucle interne passe à l'itération suivante, au lieu d'accéder à l'élément mémoire d'à côté, on fait un saut, qui peut sortir du cache, et là c'est le drame. Un défaut de cache à chaque itération de boucle, ça pardonne pas.

Mais la première chose qui me vient à l'esprit, c'est « quid de pypy ? »

avec PyPy 2.0.2 with GCC 4.7.2

5.6s

mais le support de numpy est encore balbutiant en pypy…

Non, c'était un « bug », problème de taille de bounding box, grâce aux conseils avisés d'un collègue, c'est corrigé ! Merci pour l'œil de Lynx !

Et en ascii art ?

                                 ##
                                 ##
                                 ###
                    ##########   ###
                  #############   ###
              ##################  ####
              ################### # ###
            #########   ########### ####
         ############## ##########   ###
    ############# ## #############    ###
##############     ##  ###########    ###
              #######    ######  ##  ####
         #############    ####    #  ###
      ################    ####    ######
    ##################     ####   #####
   ##############     ###   ####   ####     ############
 ############            ### ####  ###########################
 ##  #######                #############                ########
###########                ##############                     ######
############           #########################                 ####
###  #########     ################################               ####
######################################################              ###
 ####   ################     ##################### ######           ####
  ###   ###  #####    ##    ####### #############   ##   ###        ####     # #
   #######    ####    ########               #####         #####    ####     ##
     ######  ###### #######                     ######            #####     ##
        #############                              #########################

Ahah, c'est moi ;-)

Et bientôt il y aura les modules.

Oh ! une ref ?

moi pas comprendre ^^!

D'ailleurs c'est la même personne que tu as rencontré à l'autre bout de la planète.

À qui se rapporte de c' ?

Le seul inconvénient, c’est qu’il faut prévoir tous les cas possibles dans le .cpp

Et oui. Malheureusement, la plupart des algos sont génériques, à la STL et il existe une infinité de cas possibles…

Ceci dit ce n'est pas le cas de tous les algos, et on pourrait quand même les pré-instancier pour les types les plus connus.

Ensuite (et indépendamment des problèmes de temps de compilation) c'est assez confortable de ne livrer que des fichiers d'en-tête, comme ça on a un paquet composé uniquement de .py et de .hpp qui est donc relativement facile à distribuer. Bref, beurre, argent du beurre, crémière…

Pour le mot clef export, je croyais qu'il avait été supprimé du standard car supporté par un unique compilo avant 2011, mais enfin il est juste passé en obsolescence (je ne cite pas le standard).