serge_sans_paille a écrit 251 commentaires

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

Ça fait presque 40% des nouveautés majeures faites uniquement par les français, et les français sont impliqués dans 50% des nouveautés majeures. D'ici Python 3.5 voir Python 3.6, on a prévu de traduire les mots clés en français, puis de mettre du fromage dans la stdlib.

J'ai ri :-)

Une faute de frappe, de style
select.wehre = user.name == "Toto"
ne sera pas détectée.

On peut toujours surcharger __setattr__ pour faire ce genre de vérification, non ?

Salut,
Je ne comprends pas bien ta question : j'ai choisi le langage Python comme langage d'entrée car c'est un langage qui a une communauté scientifique assez forte, et que j'utilise (comme ça je suis aussi utilisateur de mon outil, ce qui me garanti d'avoir au moins un utilisateur ;-) ). Je ne connais rien à R mis à part que c'est utilisé par des statisticiens.

Comme c'est un projet perso, pas de cahier des charges, mais si tu as pleins de sous et ne sais qu'en faire, je cherche du boulot pour octobre ;-)

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

Comment te dire :
http://france.lachainemeteo.com/meteo-france/ville/previsions-meteo-plouzane-4130-0.php

le problème viens aussi du côté bas niveau du code, faire comprendre > à un compilateur la sémantique de

for (int i = 0; i < N-2; i += 2) {
a[i+2] = f(i);
}

n'est pas évident, mais possible tant qu'on ne fasse pas de magie > avec l'arithmétique des pointeurs.

Alors qu'on compilateur aura beaucoup plus de faciliter à comprendre

a[2:] = map(f, range(len(a) - 2)

On peut déterminer si map est parallèle et si ça vaut le coup de paralléliser, en poussant un peu le bouchon et suivant l'utilisation faite de a par la suite, on peut transformer le map en itertools.imap etc

J'avais même fait l'expérience avec un étudiant, et l'écriture d'un code C sans connaître toute les ficelles donnait lieu à un code moins performant que le même algo décrit dans un langage de haut niveau qu'un compilo a pu optimiser. Et en mettant un expert, il remettait la nique au compilo d'ailleurs (ouf!).

L'idée sous-jacente serait qu'il est plus facile d'encoder du savoir faire spécifique dans un compilo pour un langage de haut niveau que dans un compilo pour langage de bas niveau. Un peu ce qui se passe avec les DSLs d'ailleurs.

oui oui—4 cœurs i7 hyperthreadés :-)