serge_sans_paille a écrit 269 commentaires

Tu as... carrément raison :-) Merci pour la piqure de rappel, les exemples ont été écrits de tête, je serais surpris que ce soit la seule erreur...

Mouarf, je me suis vautré sur l'indentation des listes à puces, si un modo peut modifier ça, c'est cool !

En shell POSIX, pour déplacer une fichier vers un répertoire qui porte son nom, tu peux utiliser ça :

src=A.pdf # to replace with the script argument or whatever contex you use
mv "$src" "${src%.*}/"

Derrière la petite pique trollesque, tu pointes du doigt un vrai problème, qui est cependant partagé par d'autres couples (langage , compilateur) : le langage donne très peu de garantie d'optimisation ou non de certaines constructions, et le développeur en est réduit à faire confiance au compilateur pour apporter les propriétés de performance, abstraction à coût zéro etc. Autrement dit la phrase « C++ donne du code rapide » est bien moins pertinente que « GCC arrive généralement a compiler efficacement un code C++ ». Ce n'est pas du tout une propriété du langage, et du coup il est difficile de raisonner dessus...

Mort à toutes les polices, du ouèbe et d'ailleurs !

Et pourtant il y a plein de polices utiles voire très jolies !

un problème dont on n'est pas sûr qu'il en soit un

J'ai effectivement assez peu motivé mon cas d'usage. Si tu as une structure de tableau qui a comme variable membre un tableau qui contient à chaque indice le nombre d'éléments dans cette dimension, par exemple :

template<class T, size_t N>
class ndarray {
 std::array<long, N> shape;
 T* data;
};

Si l'utilisateur sait que la dernière dimension vaut toujours 3, par exemple parce que c'est une matrice de pixels, cette représentation va être pénalisante quand on voudra par courir la dernière dimension, car le compilateur n'a pas moyen d'éviter l'itération. En résultent des temps d'exécution déplorables.

for(long i = 0, n = a.shape[2]; i < n; ++i)
 a.data[index(i)];

Si on encode dans le type de shape l'information comme quoi la dernière dimension est constante (et petite), et que cette constante est connue, on arrive à

template<class T, class pS>
class ndarray {
 pS shape;
 T* data;
};

et le compilo aura toutes les informations pour dérouler complètement l'itération.

une solution dont on n'est pas sûr qu'elle a un intérêt

J'espère que maintenant qu'elle est motivée, son intérêt transparait mieux :-)

je suis peut-être un peu sec

Le demi-sec, c'est moyen, j'ai une nette préférence pour le brut bien râpeu, mais bon, les goûts et les couleurs...

C'est surtout lors des rebuilds que ninja brille (curieux pour une profession de l'ombre, n'est ce pas ?). Comme le dit cet article c'est surtout valable pour les softs de grosse taille, mais à ce niveau ça devient significatif.

Une présentation par le dev de meson qui complète bien ce journal.

Côté Android la compilation du code C++ se fait avec l'outil ndk-build, qui est en réalité une interface à GNU Make

On notera que depuis quelques temps, ils offrent aussi une intégration à CMake.

Je ne trouve pas une page explicite qui liste les fonction numpy supportées, c'est dommage !

http://pythran.readthedocs.io/en/latest/SUPPORT.html

Tu y liras que np.mgrid n'est pas supporté. Je vais jouer avec ton bout de code, il est marrant. J'ai ouvert un ticket dessus pour garder une trace https://github.com/serge-sans-paille/pythran/issues/918

C'est effectivement totalement (shellement?) ironique. J'avais laissé la porte ouverte pour faire ça, mais une petite porte. Et voilà que des gens s'engouffrent dedans avec enthousiasme.

Je jubile.

complètement :-/ Tu remarqueras aussi le joli travail de l'éditeur qui a pas été fichu de faire le rendu correct des commandes laTeX (bon, j'aurais du mieux relire son pre print aussi hein)

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.