serge_sans_paille a écrit 258 commentaires

Suggestion de lecture de ton commentaire, qui à défaut de te rendre le moral, pourrait te faire sentir moins seul : n'est ce pas la tendance générale de notre société ? La communication plutôt que l'action ? Le paraître plutôt que l'être ? La forme plus que le fond ?

En tout cas, avoir d'autres centres d'intérêt que l'informatique permet d'aborder 2020 plus sereinement !

Dans la même veine

>>> 'weak' > 'strong'
True

Ahhh quel monde idéal :-)

Cela un sens d'avoir un AST de haut niveau pour faire des optims de haut niveau et ensuite de générer le C++ ?

C'est ce qu'on fait et oui ça a un sens : on fait les optims qui ont du sens au niveau Python, et qui seraient infaisable à un plus bas niveau (ou du moins plus dures à prouver, soyons modestes). Et on délègue le reste au compilo, qui fait lui aussi des optims à son niveau (p.e. la copy elision etc) et ensuite le compilateur, disons clang, génère de l'IR LLVM et encore d'autres optimisations arrivent. N'est-ce pas fantastique ? ;-)

pour l'IR LLVM, elle est de très bas niveau par rapport à ce qu'on veut faire, et surtout il n'y a pas de types paramétrés, alors que ceux ci sont au coeur de Pythran (pythran travaille sur des fonctions python polymorphes, génères des fonction c++ polymorphiques (template) et c'est à la toute fin que les annotations sont prises en compte. Ainsi on peut traduire du code python en C++, et l'embarquer dans une appli native.

Oui, je me demandais si tu parlais de types optionnels au sens de Option Type ou au sens de types que l'on peut ajouter de façon optionnelle. Cela semble être le second point.

Pythran pourrait utiliser ces types, mais comme ils sont optionnels, il doit surtout savoir faire sans :-) Et dans ce cas, autant faire sans !

L'intérêt serait serait pourtant de bénéficier de l'inférence / vérification de type par mypy, idéalement en en faisant une dépendance de Pythran…

L'ownership, c'est le suivi du cycle de vie de la mémoire ?

Dans mon jargon, oui :-) Pour le moment tous les types non scalaires passent par un shared_ptr, on doit pouvoir supprimer ça dans pas mal de cas !

Il s'agit de fonction de base à rendre vectorielle en C++ ?

oui

On a fait ça en partie : suppression de l'assignation de tuple, des lambda, des fonctions imbriquées… on pourrait effectivement aller encore plus loin dans ce sens, je partage ton point de vue sur les effets bénéfiques de l'approche. Quand à la recherche d'un « point bas » on fait ça aussi, avec une limite sur le nombre d'itérations quand même !

Je pense avoir vu une présentation de Lisaac aux journées de la compilation françaises, à Aussois. Probablement donnée par toi ?

Les fondements théoriques de Pythran sont assez flous et mouvants, mais il reste des choses amusantes à faire, soit au niveau du typage si c'est un truc qui te branche, ou également (mais c'est un gros chantier) sur l'ownership.

Plus humblement, certaines fonctions de pythonic gagneraient à avoir une version vectorielle, ça peut être un bon sujet pour commencer !

Arf mon exemple n'est pas extra alors… Et j'apprends quelque chose. Merci !

Disons que ça permet quand même d'avoir l'optimisation suivant le type ?

mmmh, je ne suis pas sur de comprendre, ou disons que je peux comprendre plusieurs choses, tu peux détailler ?

Est-ce que pour des raisons de performance tu peux modifier le layout mémoire utilisé en C++ ?
On peut mais on ne le fait pas. Pour le moment on garde le layout C et on ne vectorise que les opérations point à point. Je ne suis pas encore allé gratter de ce côté.

l'optimisation de base étant de trier de façon décroissante les champs d'une structure

Et le AoS ou SoA, non ? Comme on n'a pas de types custom, le cas le plus proche serait les tableaux de complexes. Mais on ne fait pas actuellement. On pourrait par contre faire une passe qui décide du bon layout et intégrer ça à la génération de code, oui.

Tu as un peu de temps de dev libre ? Tes remarques sont souvent ultra pertinentes ;-)

Un mécanisme de plugin est envisageable, mais je crains que cela ne change rien à la difficulté intrinsèque de l'exercice, qui doit beaucoup, avouons-le, à l'absence de documentation de haut niveau sur pythonic, mais pas que.

Pour le moment, plutôt que G'mic, la tendance serait de se rapprocher de xtensor qui a l'avantage d'être header-only (ça facilite la distribution)

https://github.com/serge-sans-paille/pythran/issues/155 ouvert en 2013 :-) Il y a du travail, c'est sûr… je ne sais pas quoi te dire de plus, je comprends l'importance de ce dev, je n'ai juste pas le temps nécessaire pour rentrer de dans tout de suite. Une grosse envie de contribuer poindrait-elle en toi ?

Je suis d'autant plus flatté de parler de ce sujet ici car, du fait de sa syntaxe simple et ses excellentes performances, Pythran est de loin mon favori, et je sais que son créateur traîne ses guêtres par ici

>^-^<

Malgré le plaisir coupable que j'ai à lire ces lignes, je me demande si cela introduit un biais dans la mise en oeuvre de la comparaison ? Il est tellement facile d'obtenir ce que l'on veut quand on sait ce que l'on cherche.

Ceci dit, avec le même biais que toi, j'arrive aux mêmes conclusions. Cython est un chouette langage hybride, il perd en investissement de départ et en pérennité de cet investissement ce qu'il gagne en flexibilité. Numba fournit un JIT ce qui le rend facile d'accès, mais à un support moindre des fonctions haut niveau de Numpy.

Il était « par design » multiplateforme, avec quelques ajustements à faire qui m'ont demandé un peu de sueur, mais finalement pas tant que ça :-)

Si un modo passe dans le coin, tout à mon enthousiasme j'ai oublié l'importante passe de relecture :

• de code s de haut niveau écrits
• a été publié e
• il pythran est maintenant empaqueté
• la la 0.9.3
• pas encore empaqueté e
• beniget .

Merci !

C++ semble vraiment être un langage d'expert.

C'est surtout un langage de grands enfants : https://twitter.com/MJKlaim/status/1139856421867180033

oki, envoie moi un mail que je te transfère ça ! Tu trouveras mon contact sur ma page perso.

Vote et soutiens-la si le sujet t'intéresse :)

Merci ! J'avoue que mon investissement dans la communauté Windowsienne reste minimaliste hein. Je me trouve même déjà bien altruiste de faire tous ces efforts d'empaquetage !

En vrai, comme évoqué dans le nourjal, rpath ne résout qu'une partie des problèmes, vu qu'il est positionné sur le code généré par Pythran, dont je ne maîtirse pas l'environnement d'exécution futur. Il est heureusement possible à l'utilisateur de Pythran de positionner le rpath lui même, ou d'aller faire un coup de xxd pour éditer le binaire final (mais beurk hein :-))

J'aime bien cette idée de fichier de conf nix qui sert de documentation de dépendances. D'une certaine façon, le .travis.yml et le .appveyor.yml jouent un rôle similaire.

Je reste néanmoins persuadé qu'il est plus facile pour l'utilisateur de rentrer un simple pip install pythran et que ça juste marche :-/ C'est un peu le problème du standard de fait.

Même ainsi, je me demande quelle doit être le mode par défaut : lier avec la lib blas système si elle est présente ? Les blas statiques empaquetées par mes soins ?

Le plus proche que l'on pourrait avoir est en discussion, je te recommande la lecture de ce fil :

https://www.freelists.org/post/pythran/Use-pythran-to-deploy-tensorflow-models

A quel point pythran s'éloigne de python ?

Pythran ne supporte pas les classes, et ne supporte pas le code polymorphique.

A quel point, serait-il compliqué de compiler du code normal ou une partie de celui-ci ?

Pour compiler une partie, on peut regarder du côté de https://transonic.readthedocs.io/en/latest/

Plus la base d'utilisateur augmente, plus la base de contributeurs potentiels aussi, non ?

Pas si sûr… l'écosystème Python scientifique fait que les compétences Compilation, C++ et calcul intensif ne se retrouvent pas forcément dans la base d'utilisateurs. Mais on commence à avoir quelques contributions significatives, donc je suis content !

Mise à jour de GCC qui fait du 9

Et son camarade de classe Clang/LLVM taille maintenant du 8

Ca n'est pas dans le projet LLVM (pour le moment?)

À ce sujet, la lecture de ce thread est intéressante.

Celui là est facile : appel sans argument d'une lambda sans capture et sans argument en C++11.

Notons qu'avec des virgules ça devient du python valide !

[],(),{},();

Exact, merci !