serge_sans_paille a écrit 258 commentaires

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

Youpi, des encouragements !
Comme dit dans le journal, on fait une sortie stable, ça te laisse un peu de temps :-)

J'aurais tendance à être d'accord avec ce commentaire. Il y a plusieurs avantages à apprendre l'**algorithmique** avec Python, p.e. comprendre la complexité d'un algorithme qui compte le nombre d'éléments uniques dans une séquence :

count_uniq = lambda l : len(set(l))

Ou pour compter l'élément qui apparaît le plus souvent :

def most_frequent_element(l):
   d = dict()
   for elem in l:
       d[elem] = 1 + d.get(elem, 0)
   return max((y,x) for x,y in d.iteritems())

Et l'avantage de ses deux algos (soigneusement choisis, je te le concède) c'est qu'ils sont génériques, donc l'information de type, bah… tu t'en fiche. On peut même embêter le prof de physique et mettre des carottes et des patates :-)

Le premier lien est passionnant, merci !

Tiens, bonne idée, je vais discuter avec eux :-)

Plutôt que de perdre ton temps avec un langage dont la propriété principale n'est pas la performance, tu ne pourrais pas utiliser ton talent pour coder les parties nécessaires dans un langage adapté puis faire le lien avec la JVM ?

Et ne loupez le prochain épisode : pythran vs. numba

(au kazou, rappelons que l'optimisation prématurée est mère de tous les maux)

Ça semble intéressant, mais je n’y connais rien. Je constate que ton projet semble concerner avant tout le calcul.

Farpaitement

Qu’est-ce que tu conseillerais pour celui qui manipule massivement des strings et des expressions régulières dans ses programmes ?

Pas évident… en se basant sur ce bench tu vois que le moteur de regexp de Python n'est pas le plus flamboyant (niveaux perf) de la planète. Une possibilité serait d'utiliser un backend de regex plus performant (celui de perl, semble-t-il). Il y en a un dans C++11 mais je ne sais pas ce qu'il vaut.

Pour ce qui est de la manip' de string, c'est un domaine d'optimisation que je connais peu. Shedskin supporte le module re et la manipulation de chaîne, tu peux regarder ce que ça donne…

PyPy est généralement très bon (cf. les benchs du post), si tu l'essaie sur ton cas et nous donne un retour, ça peut intéresser du monde (en tout cas ça m'intéresse).

Et oui, l'idée serait de compiler ça en module natif appelable depuis python. c'est ce que fait Pythran , mais certainement pas pour ton cas.

Je suis curieux : quelle différence entre l'interface Python2 et l'interface Python3 ? Un changement de l'API C ?

J'ai oublié de rendre à césar, alors que c'est important : pour la vectorisation générique, je me base sur boost.simd qui est inclue dans nt²

Même si je doute de la pertinence de la comparaison, j'ai demandé à un étudiant de coder l'algo décrit ci-dessue n C++ avec de l'OpenMP. Ça donne ça :

    struct timeval start, stop;
    gettimeofday(&start,0);
    double h[10000];
    std::fill(h, h+10000, 1);
    double k[10000];
    std::fill(k, k+10000, 1);
    double l[10000];

#pragma omp parallel for
    for(int i=0; i<10000; i++)
        l[i] = std::sqrt(h[i] * h[i] + k[i] * k[i]);

    gettimeofday(&stop,0);
    std::cout << (stop.tv_usec - start.tv_usec) << "micro sec" << std::endl;

ce qui me parait raisonnable.

$> make CXXFLAGS='-O3 -march=native' test
$> ./test # j'ai fait la médiane sur 100 runs
486micro sec

Ce qu'on peut lire comme : pas mal, mais g++-4.7 ne vectorise pas la boucle mesurée (j'ai vérifié)et nous on utilise des infos de haut niveau pour le faire, donc… on lui colle la vectorisation dans les dents.

connaissais pas :-) Je vais regarder avec intérêt, merci!

Merci! Hésite pas à passer sur freenode #pythran pour nous donner des bouts de code, on en cherche !

Il manque pas mal d'intrinsèques de base, et la manipulation de sous tableaux… donc pas mal d'efforts encore :-)

Tu veux dire que les trois liens Wikipedia n'aident pas ?

Si je te dis que numpy crée un tableau temporaire par opération, tu imagines le surcoût en:

• allocation mémoire / parcours de tableau (prix des accès mémoires)
• coût de contrôle (prix de l'itération)

en plus la vectorisation (i.e. faire 4 sommes en une opération vectorielle) n'aide pas car on se paie 1 chargement mémoire, 1 opération, 1 déchargement mémoire.

Pythran fusionne les boucles, ce qui augmente l'intensité de calcul (on charge une fois les opérandes, on calcule beaucoup dessus, on décharge le résultat) et permet d'avoir un gros bénéfice lié à la vectorisation.

La parallélisation de la boucle englobante vient ajouter au tout.

Pas de comparaison tu dis ? Et la comparaison avec numexpr, hein ? Pour comparer au C++, forcément si le dev connait et applique les techniques sus-citées, il ira au moins aussi vite. Mais ça lui prendra pas trois lignes de code… Par contre une comparaison à numpypy et numba s'impose en effet :-)

voili voilou, j'espère avoir mieux argumenté là !

Elle est très intéressante cette thèse,

Owi, continue à envoyer des fleurs comme ça, l'ego aime :-)

Pour le peu que j'ai vu de copperhead, tu dois te plier à la sémantique du GPU. Trop brainfuck pour moi et pour la plupart de gens.

Je suis d'accord.

L'idéal serait évidemment que cet outil de conversion soit prouvé en Coq ou quelques chose de ce genre.
Je n'ai qu'une vie, qui est déjà bien remplie :-)

Si tu as des p'tits bouts de code qui trainent, hésitent pas à les partager, ça peut guider les devs :-)

Wooo, un lecteur de ma thèse. Si on m'avait dis que cela arriverait un jour :-)

Niveau optimisations, ce sera d'abord les instructions vectorielles qui vont y passer, et la fusion d'opérateur. Quand on regarde du code numpy, c'est trop tentant !

Et puis l'analyse de préconditions aussi…

Les GPUs c'est pas pour tout de suite non. regarde du côté de copperhead si tu es pressé.

J'essaie de faire attention à la conception du compilo aussi, pour rendre l'injection de passes facile :-)

Yes, ça c'est du code comme on aime.

Dès que pythran supporte les deux-trois fonctions numpy qui manquent, je te réponds :-)
Mais c'est clairement la marche à suivre !

(comme je manque un peu de temps actuellement, ça risque de pas être implémenté tout de suite. Un moyen de te tenir au courant ?)