serge_sans_paille a écrit 269 commentaires

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 !

J'étudiais https://github.com/llvm-mirror/llvm/commit/f724c01683a66e2916b0f5ce26b98b59fd5df59d

Si le types est trivialement copiable alors un std::memcpy est valide.

Sexy :-) par contre dans le pire des cas tu es en O(n^2) non ?

En théorie oui, et c'est une proposition sacrément intéressante que tu fais là.

En pratique je n'ai pas le bagage pour ça mais (au choix, non exclusif)

• tu pourrais me pointer vers une doc de référence explicite sur le sujet ?
• tu pourrais me pointer vers une lib qui implémente ton idée
• tu as envie d'implémenter ça dans pythran ?

Peux tu expliquer pourquoi il y a un speed-up sur pythran sans vectorisation ?

C'est principalement du à la fusion de boucles, comme expliqué ici : http://serge-sans-paille.github.io/pythran-stories/pythran-case-resampling.html

On peut imaginer un système d'enregistrement de plugin avec des paramètres optionnels (je dis pas que c'est le bon design hein) :

void some_plugin();
template<class F>
void register_(F plugin) {
 plugin(1/*verbosity*/);
}
int main() {
 register_(function_cast<void(int)>(some_plugin));
 return 0;
}

Ça permet d'avoir des paramètres optionnels pour les plugins.

Super intéressant, merci !

Cette vidéo explique très bien un tas de concepts liés : https://www.youtube.com/watch?v=g7entxbQOCc

Une autre source de undefined behaviour est quand on a des pointeur extern "C"

Par exemple:

extern "C" int my_function(int); // Une fonction d'une bibliothèque C

int foo() {
int (*f)(int) = my_function; // Compile sans warnings
f(42); // undefined behaviour

// undefined behaviour dans function_cast::operator()
return apply(my_function);
}

Peux tu détailler l'origine de ce comportement indéfini ? Je pensais que extern "C" changeait juste le name mangling, ça changerait aussi la convention d'appel?

Un cas proche dans LLVM (bon, plus exactement dans compiler-rt), mais qui porte sur le type de retour :

https://github.com/llvm-mirror/compiler-rt/blob/23b063668e563dd5cc8fc37e00c3199a9afa595f/lib/sanitizer_common/sanitizer_linux.cc#L1715

On retrouve la même dans https://github.com/python/cpython/pull/6008 d'ailleurs.

Un autre cas détecté par GCC qui fait froid dans le dos

../lib/IR/Core.cpp:97:48: warning: cast between incompatible function types from 'llvm::DiagnosticHandler::DiagnosticHandlerTy' {aka 'void (*)(const llvm::DiagnosticInfo&, void*)'} to 'LLVMDiagnosticHandler' {aka 'void (*)(LLVMOpaqueDiagnosticInfo*, void*)'} [-Wcast-function-type]

Complètement d'accord, mon exemple est bien mauvais :-) Merci d'avoir pointé ça !

Si ça peut te rassurer, ou à défaut t'arracher un sourire, j'ai un sentiment similaire en assistant à CppCon. On est tous le noob de quelqu'un :-)

Mais appeler ses libs ne demandent pas d'utiliser des intrasecs SIMD, si ?

Pour xsimd, non (la lib fournit une abstraction des registres vectoriels).

Pour sleef, elle fournit de nouvelles fonctions compatibles avec l'usage d'intrinsèques, comme le montre cet exemple tiré de leur doc

#include <stdio.h>
#include <x86intrin.h>
#include <sleef.h>
int main(int argc, char **argv) {
 double a[] = {2, 10};
 double b[] = {3, 20};
 __m128d va, vb, vc;
 va = _mm_loadu_pd(a);
 vb = _mm_loadu_pd(b);
 vc = Sleef_powd2_u10(va, vb);
 double c[2];
 _mm_storeu_pd(c, vc);
 printf("pow(%g, %g) = %g\n", a[0], b[0], c[0]);
 printf("pow(%g, %g) = %g\n", a[1], b[1], c[1]);
}

Ce qui répond un peu à la question :-) Il y a plusieurs libs qui fournissent une version vectorisée de la makorité des fonctions de la lib math, p.e. https://software.intel.com/en-us/node/524352, http://sleef.org/, ou https://github.com/QuantStack/xsimd. Pythran utilise ces libs car le compilo ne le fait pas (mais ça bouge, et llvm sait représenter ça au niveau IR, cf. https://reviews.llvm.org/D24951)

Malheureusement non. Petit exemple qui illustre mes propos : https://godbolt.org/z/pNNPhx