serge_sans_paille a écrit 263 commentaires

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

Et tu es bien content que d'autres réfléchissent à ta place sur une façon d'exécuter de manière décente ta ligne. Normal. Si tu veux la perf de la perf, faut aller la chercher et se retrousser les manches, sinon, tu es content que d'autres capitalisent leur savoir faire dans un outil.

C'est vrai que je ne me suis pas fendu d'un long commentaire sur les raisons de ces résultats… disons que cela alimente le débat… choquer pour provoquer la discussion :-)

Les tableaux utilisés dans le code Python sont des tableaux NumPy, et pas des listes de listes. Ces tableaux ne sont ni plus ni moins que des tableaux natifs encapsulés. Les accès se font en row major en C et en Python et le code donné en tient bien sûr compte.

Autrement dit : très peu de défauts de cache dans cet exemple, que ce soit pour le code C (cf. http://ridee.enstb.org/sguelton/hyantes_bench.tgz) ou le code Python, ou le code C++ généré d'ailleurs.

Pour en savoir plus: The NumPy array: a structure for efficient numerical computation

Oui c'est ça ! Si le code est implicitement non polymorphe, on s'en sort pas trop mal. Sinon on crache une erreur c++ de 50 lignes de long :-)

Homme de peu de foi !

Test efectué à l'instant avec la branche compas2013 du dépot sus-cité
Sur l'archive http://ridee.enstb.org/sguelton/hyantes_bench.tgz

En supposant pythran installé quelque par

# la ref
clang -O2 hyantes.c -lm -o hyantes
time ./hyantes 'Rhone-alpesXYLongLat_pop.txt' 1.1 32 4 35 0.01 40 > /dev/null
real    0m22.223s

CXX=clang++ pythran -O2 hyantes_core.py
time python hyantes.py > /dev/null
real    0m22.767s

# pareil avec gcc
gcc -O2 hyantes.c -lm -o hyantes
time ./hyantes 'Rhone-alpesXYLongLat_pop.txt' 1.1 32 4 35 0.01 40 > /dev/null
real    0m25.905s

CXX=g++ python ~/sources/pythran/scripts/pythran -O2 hyantes_core.py
time python hyantes.py > /dev/null
real    0m26.362s

Le tout sur un Core I7.

à vot' service Saint Thomas !

En utilisant le moteur de template fourni par le module string :

# parse config file
kv = dict()  # holds the key/value
with file('def.cfg') as f:
  for line in f:
    k, v = line.split('=',1)
    kv[k.strip()] = v.strip()

# load the template
from string import Template
tpl = Template(file('tpl.txt').read())

# perform substitution
print tpl.substitute(**kv)

et éventuellement renommer le cpp en tpp pour préciser qu'il s'agit d'un template ?)

find /usr/include/c++/4.7 (et une paire d'yeux aguerris) nous informe que gcc stocke ça sous forme de .tcc.

Je dirais question de compilo / archi. Je n'observe pas ce phénomène sur ma machine (amd64/debian sid)

Pour le moment, tu prends un module python, disons foo.py, tu l'annotes légèrement

#pythran export ma_fonction(int list, float set, int:str dict)

puis

pythran -O3 -DNDEBUG -g foo.py -o foo.so

et ensuite tu peux utiliser le module foocomme un module python normal, sauf que c'est le code natif qui s'execute

from foo import ma_fonction

# là c'est le code natif qui s'execute si foo.so est dans le path
ma_fonction(range(10000), { 1./i for i in xrange(1,1000) }, { i, str(i) for i in range(10) })

l'avantage c'est que même si pythran disparait de ton environnement, tu touches rien à ton code et il continue de fonctionner. Le seul changement, c'est d'isoler les parties calcul intensif dans un module, mais on pourrait presque dire que c'est pas une mauvaise pratique d'ingénierie :-)

Remarque que rien n'empêche d'écrire un décorateur @pythran qui compile à la volée, mais le temps fuit sous mon clavier, et j'ai pas eu de demandes dans ce sens pour le moment.

Si tu as un code à passer, on peut en discuter sur Freenode #pythran ou pythran@freelists.org :-)

Oui, oui, je fais déjà tout ça. Mon exemple n'était pas bon

def foo(bar): bar.append(1)
a= list()
bar(a)
print(a)

traduit comme tu le proposes ça donnerait

pythran::vector<MaisQuelType> a;
bar()(a);
pythran::print(a);

L'info MaisQuelType == int vient de append caché dans foo. Et malheureusement je n'ai pas trouvé de moyen de faire remonter cette info au moment de l'instanciation, donc je suis obliger de mettre ça dans l'inférence de type interprocédurale… je ne sais pas si c'est plus clair comme ça ?

C'est ce que fait https://github.com/numba/numba. (du moins pour la deuxième alternative). Tu ne trouves pas ça ultra moche ? Moi si. Bon ça garde la propriété « compatible python » mais je trouve ça très intrusif.

Pour le moment on donne quelques directives pour les fonctions exportées

#pythran export fibo(int)

mais elles sont facultatives, auquel cas on génère un bon gros .h que l'utilisateur peut instancier comme il le sent. Donc on ne peut pas se servire de ses infos pour l'inférence de type.

mmmh, c'est un peu compliqué à expliquer, mais je me lance. Déjà tout est fonction, els appels de méthodes sont convertis en appels de fonctions. Prenons le cas de la fonction list.append. Les informations associées sont

1. elle revoie None
2. elle nous informe que le type de son premier paramètre self doit être compatible avec liste de . Je dis compatible parceque si on ajoute des int puis des float, au final on aura des float.

ces informations sont spécifiées en Pythran par une forme de signature de l'intrinsèque.
ensuite considérons, hors de son contexte (par exemple si la fonction n'est jamais appelée dans le module, on ne peut donc pas savoir le type des paramètres)

class ique(object):
   def append(self, other):pass

def foo(l,a):
  l.append(a)

que faire pour append ? Je suis incapable de décider si c'est le append de list ou celui de ique. Quelles informations de type utiliser?

Vu autrement, le problème est que je veux générer des fonctions c++ polymorphiques, et donc on ne manipule ques des types symboliques ce qui fait que quand j'ai un appel de méthode, je ne sais pas (jusque l'instanciation, mais qui arrive bien plus tard) quel est le type exact des objets que je manipule, je connais juste les relations entre les types.

En théorie oui. D'ailleurs shedskin le fait.
Deux points me gênent pour le moment :

1. Gestion Mémoire :
   En utilisant l'hypothèse types non récursifs on peut se permettre une gestion simplifiée de la mémoire (par compteurs de référence). Bon, on peut toujours refuser les classes qui induisent des dépendances de type circulaire…

2. Inférence de type :
   Le moteur d'inférence de type de Pythran a quelques limitations. Quand je rencontre un appel de méthode, je ne sais pas à quelle classe elle est rattachée. Quand l'ensemble des méthodes (i.e. celles des conteneurs) est connu, je m'en sors très bien, mais sinon, je pense que ça va être coton.

Oui ! Plus précisément

Pour la lib standard

• list -> std::vector
• set -> std::unordered_set
• dict -> std::unordered_map
• tuple -> std::tuple (assez costaud celui là)
• print(truc, muche) -> std::cout << truc << ' ' << muche

Pour l'inférence de type

decltype et declval font des merveilles

Pour la gestion mémoire

vive les std::shared_ptr

Petit exemple

def foo(a):
  b = bar
  return b() + a
foo(10)

qui devient (en simplifiant)

struct foo {
  template<class T>
  decltype(std::declval<b>()() + std::declval<T>()) operator()(T&& a) {
    auto b = bar();
    return b() + a;
  }
};
foo()(10);

La crème de la crème

mais la crème, c'est les variadic templates qui permettent d'implémenter de façon élégante les fonctions intrinsèques de la lib standard du genre reduce et cie…