serge_sans_paille a écrit 258 commentaires

Mais mais… tu as raison, très amusant ce petit format :-)

Si tu lis bien le code std::make_index_sequence n'est pas utilisé, mais une version naïve est fournie.

Quant au plantage sous GCC, je le constate aussi, mais je l'attribuerai plutôt à une limitation de GCC :-)

J'aurais bien aimé, mais non, la raison étant que si on passe par une fonction template on aurait un truc du genre

template<class... Ts>
auto cats(Ts... args) -> decltype(([]() {
    struct _ {
        char const * strings[sizeof...(args)] = {args...};
        const std::array<unsigned, sizeof...(args)> sizes = make_sizes(args...);
  };
  return strcat_helper<_>();}()))

(parenthèsage non contractuel).

Dans ce cas le decltype dépend du type de retour de la lambda, ce qui rentre dans la catégorie lambda expression in unevaluated context et c'est interdit. Mais ça passe en c++14 il me semble (vu que le type de retour est inféré).

Ça s'appelle Boost.operators non ?

C'est pour supporter l'argument axis de numpy.argmin ou numpy.argmax dans pythran. Le commit complet, à peu près autour de la bonne ligne, est là :

https://github.com/serge-sans-paille/pythran/pull/803/files#diff-b20072554ff33a1cd786318f40ff0368R110
(attention, réponse demandant un peu de connaissance de l'API numpy)

Comme le paramètre d'entrée est une expression-tableau de dimension N (paramètre template), et qu'on veut calculer argmin en suivant l'axe axis (paramètre non connu à la compilation), il faut générer les N patrons de boucle possibles suivant la valeur de l'axe.

Petit exemple pour N = 3, on peut vouloir générer (cas du min qui est un peu plus simple, mais c'est l'idée)

// axis == 2
for(int i = 0; i < n; i++)
    for(int j = 0; j < m; ++j)
        for(int k = 0; k < p; ++k)
           out[j, k] = min(out[j, k], in[i, j, k]);

// axis == 1
for(int i = 0; i < n; i++)
    for(int j = 0; j < m; ++j)
        for(int k = 0; k < p; ++k)
           out[i, k] = min(out[i, k], in[i, j, k]);

// axis == 0
for(int i = 0; i < n; i++)
    for(int j = 0; j < m; ++j)
        for(int k = 0; k < p; ++k)
           out[i, j] = min(out[i, j], in[i, j, k]);

le code pointé plus haut génère ces différentes boucles quelque soit N, dans le cas de argmin, en gardant un typage correct.

Je ne sais pas si je suis clair :-/

La fonction template en question est marquée noinline, ceci explique cela :-)

de briller en societe

complètement !

On peut aussi voir ça comme un exercice de style, une sorte de jeu, ce qui est le cas de ce journal :-)

L(e seul) avantage du deuxième, c'est que tu peux augmenter le nombre d'éléments du switch à volonté, sans avoir à spawner les copier-coller :-)

Ou bien c'est pour bien ranger le code ?

C'est ça !

Merci à toi de partager quelques instants de ton quotidien avec nous, de démystifier l'activité de recherche et montrer à quoi « ça sert » puisque l'on vit dans un monde où la finalité semble importante à beaucoup :-/

Quelques questions ! Tu dis que ta communauté est en contact avec celle qui poussent des langages comme Julia. Concrètement, comment se passent vos échanges, sur quels types de questions vous penchez vous etc ? Êtes-vous en contact avec la communauté LLVM pour aller vers des transformations prouvées, faire évoluer l'IR etc ?

Et tu n'as pas parlé d'une partie qui me semble prendre de plus en plus de temps dans le monde académique : la recherche de financement. Est-ce parce que l'INRIA est protecteur de ce point de vue, parce que c'est une partie négligeable dans ton cas, autre ?

Encore merci pour l'effort de vulgarisation et de partage !

Et pour éviter les problèmes de genre, ont parle aussi d'une truelle !

Ou un Bizu :-)

Pour un rol portable et efficace, il y a : https://blog.regehr.org/archives/1063 !

cf https://godbolt.org/g/TQchFT

@freejef, pour Lille, je te laisse voir avec l'organisateur.

Un grand merci pour ce journal passionnant, mêlant passion, code et humanisme. Je ne sais pas trop comment exprimer ça mais il se dégage de ce journal un ton de calme sérénité admirable. Ça donne envie !

Oh, et merci de m'avoir fait découvrir le Principe de subsidiarité !

Si l'original prend 1s, le nouveau temps est de 0.76s. Ça prend moins de temps, ça va plus vite.

Si un modérateur passe dans le coin : il manque un s à scientifique dans le titre, et dans la note de bas de page numéro 1, il faut remplacer chines par chiens sinon c'est moins drôle.

Merci pour ton journal qui m'a motivé à ajouter le support Pythran pour ce paquet ! La PR débarquera sous peu :-)

lu dans le README

The efficiency of the pure NumPy/mpi4py solver has been enhanced using Cython for certain routines.

Donc triche :-) Ce n'est plus du Python mais un langage hybride…

Qu'est-ce qui compile le plus vite ? gperf + le compilateur C, ou le code en C++ ?

Aucune idée. Je driais gperf +C intuitivement.

Qu'est-ce que tu entends exactement par le fait que olaf est moins robuste ?

C'est un bonhomme de neige, alors il fond :-)

En vrai, cette fonction de hash a de forte chance de toujours donner des collisions, donc elle est pas assez générique (j'aurais du écrire générique plutôt que robuste)

Comme en en C ou en C++, sans surprises, d'après la doc http://llvm.org/docs/LangRef.html#lshr-instruction

If op2 is (statically or dynamically) equal to or larger than the number of bits in op1, the result is undefined.
Donc undefined behavior

Ce n'est pas monstrueux, c'est le comportement uniforme des types inductifs.

j'ai ri :-)

Quand je lis la doc du projet, je ne vois aucune mention de typage statique, ça me fait plutôt penser à l'approche de Nuitka qui transforme n'importe quel code Python en programme C++ qui appelle le runtime CPython. Là ils ont ré-implem le runtime CPython il me semble, mais l'idée est la même.

D'une certaine façon, ça ressemble aussi à Pyston avec le JIT en moins.

Assez loin de Pythran finalement, puisqu'ils visent une approche générique, pas un embeded Domain Specifc Language, un langage spécialisé pour le calcul scientifique embarqué dans Python.

Sinon le fait de se concentrer sur Python2.7 (même choix que Pyston !) est discutable. On a mis plusieurs mois à supporter Python3 dans Pythran après avoir fait ce choix, je les plains :-)

La version cython utilise-t-elle le SIMD ?

Elle est compilée avec des drapeaux qui permettent la vectorisation, mais après avoir inspecté le binaire, gcc a pas réussi à vectoriser, non. Du coup ça veut dire que la version pythran a encore un soucis, mais je n'ai pas encore trouvé lequel :-)

car j'avais vraiment besoin de classes

C'est dans ma TODO liste, tiens tu attendrais quoi comme annotation #pythran export pour une classe ? C'est pas bien fixé pour moi…

Il y a un état de fai[tl] : la demande est là. Il suffit de regarder les compilos existants :

• cython
• numba
• pyston
• pypy

Et chacun de ces compilos a pour objectif principal ou auxiliaire mais en tout cas affiché d'optimiser du code Python utilisant numpy :-)