serge_sans_paille a écrit 251 commentaires

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

Très joli.

Je suis bien d'accord avec toi, il y a pleins de possibilités d'optimisations :-) Et après tes transfos, pas mal d'opportunités de vectorisation apparaissent. On s'éloigne cependant pas mal du prototype original, non ?

Le gars qui fait de la géomatique, il a pas le temps de faire le (bon) travail d'optimisation que tu as fait. Pas sûr qu'il en soit capable d'ailleurs.

Dis autrement, je préfère être celui qui maintient la version Python que la version C, et celui qui maintient la version C que la version C optimisée.

Le challenge est d'écrire l'algo le plus proche de sa description, et de voir ce qu'un compilo peut en tirer. D'ailleurs rien ne m'empêche (au moins pour la mémoization des appels à cos/sin) d'écrire la même variante en Python.

Ce qui confirme qu'un code évolue (comme les Pokemons !)
1. Python
2. C
3. C optimisé
4. vectorisation, parallélisation, et pourquoi pas GPUs et autres

Avec un SLOC qui augmente à chaque étape d'ailleurs.

Ton code montre que gcc a du mal à faire 1 -> 2 (ou 3 d'ailleurs)
J'essaie quant à moi de faire 0 -> 2.

Owi un rapport de bug :-)
Bon on supporte pas scipy pour le moment… mais les fonctions que tu cites ont l'air abordables.

Comme dis plus haut, pas de classes utilisateur pour le moment…
L'objectif numéro 1 c'est d'avoir les perfs du C pour des applis scientifiques, donc on a pas forcément besoin de classes utilisateur. Après, tu peux compiler la partie calcul intensif en pythran et garder le reste en Python, c'est là l'intérêt : seule la partie gourmande en calcul a besoin d'être traduite.

Boarf C ou C++, c'est pas le problème, dans les deux cas ça se traduit en code natif. C'est assez transparent pour l'utilisateur lambda.

En ce qui concerne Cython, Je suis assez de l'avis de l'auteur de Nuitka qui dit que cython ça casse la compatibilité avec le code d'origine et c'est pô bien. Pythran n'a pas ce problème.

Bon par contre cython supporte beaucoup plus de modules que nous hein, pythran c'est pas du dix ans d'âge non plus, plutôt moins d'un an sur les week end.

Salut,
ton code m'intéresse. On est en travailler sur le support NumPy (c'est pour ça que c'est dans une branche…), et ton appli peut nous servir de base. Si tu peux le mettre en ligne quelque part, ou le poster sur la mliste pythran, ce serait chouette (voire ce serait hibou).

que ce serait trop beau pour être vrai

Tu as partiellement raison. On supporte quelques modules standards (math, random…) mais pas mal de fonctionnalités du langage (list comprehension, générateurs, …). La plus grosse limitation c'est sûrement l'absence de support pour les classes utilisateurs. là encore si tu rends ton code dispo, on peut ajouter le support pour les fonctionnalités qui manquent.

Je suis surpris que tu compares les performances entre un code en python avec OpenMP vs un code en C sans OpenMP.

Mais non, la vie n'est pas remplie de personnes malhonnêtes. Pour prendre en compte les directives OpenMP dans pythran, il faut spécifier -fopenmp, tout comme gcc. Pour l'exemple du dessus, elles sont bêtement ignorées…

Pour ton problème de compil, ça semble lié à un problème de support du C++11. Quelle est la version de ton compilo ?

Ici:
Debian clang version 3.1-8
gcc (Debian 4.7.2-5) 4.7.2

En tout cas merci de pousser si loin la comparaison :-)
La suite au prochain épisode (si tu passes sur FreeNode #pythran, je me ferai un plaisir de discuter :-))

Et quel plaisir de participer au foutoir ambiant :-)