serge_sans_paille a écrit 258 commentaires

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

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)