serge_sans_paille a écrit 258 commentaires

L'histoire dont est tiré ce journal est relatée dans https://reviews.llvm.org/D104745. J'ai voulu isoler le problème pour que le journal soit plus accessible, mais tu devrais y trouver de quoi satisfaire ta légitime curiosité !

Super tip! Merci o/

C'est un chouette projet ! J'ai parcouru des bouts et j'aime bien l'approche avant/après pour motiver le passage à C++11.

Je remarque que tu as extrait certains code source dans des fichiers séparés, ça pourrait être bien d'essayer de les compiler pour garantir qu'ils sont « propres ». Par exemple je vois plusieurs fonctions main renvoyant int mais sans return. Ça ne change rien au discours de fond, mais fournir des exemples sans warning ajoute un côté classou à l'ensemble à mon avis.

On pourrait imaginer que le compilo mémoise l'appel à la fonction constexpr - j'imagine que c'est valable et on retomberait sur nos pattes :-)

Chouette article, sur le fond et la forme c'est un plaisir à lire !

Lorsqu'une compilation réussie, le compilateur joue ♪ C++ 2000 ♪ avec la voix de Johnny via Pulseaudio.

constfork permet déjà cela, à travers un

consfork "{ wait $$ && aplay jonny.mp3; }&"

C'est… excellent :-) Merci !

Chouette biblio ! Peu de temps après avoir posté ce journal, on m'a également pointé https://github.com/jfalcou/raberu qui est en C++20 mais reprend des idées des différentes approches que tu cites :-)

On notera que l'article de Jonathan Boccara que tu mentionnes répond à certaines des question de ce fil ;-)

dans ton exemple je ne sais pas dire quels sont les types valides de keyword?

Dans mon exemple, j'ai semé des auto partout pour rester pythonic. Mais tu peux aussi écrire

float & f = args.get("keyword"_kw);

si tu veux forcer le type (et/ou le documenter).

la définition des paramètres n'est pas déclaratives

Carrément.

ça génère quoi comme erreur en cas d'erreur ? (mauvais type, mauvais nom,…)

Y a des static_assert, donc tu as un message à la compil, mais moins élaboré / lisible que ce que peut produire un compilo, c'est sûr hein :-)

Ça me parait plus apporter de complexité que de solution

C'est surtout pour la beauté de la chose, pour la note artistique, le frisson de repousser les limites du langage :-)

mais en l'état on n'a plus les noms ni les types des paramètres dans la signature de l'appelé.

C'est vrai. Mais on l'a dans le corps de la fonction, surtout si on se passe de auto

int & val = args.get("some_integer_ref"_kw);

l'appelé est forcément template.

Voui :-) ensuite on peut imaginer que cet appelé face un appel à une fonction non-template une fois les arguments traités.

Comment passer des paramètres par adresse ? Combien de copies des paramètres sont faites entre l'appelant et l'appelé ? Sur cet exemple j'ai déjà une copie superflue

Merci pour ce cas test, ce bug est corrigé (et tu es crédité dans le commit !), plus de copie maintenant. Pour le passage par référence, c'est les règles de déductions des universal références classiques.

Wé c'est pas standard, mais supporté par gcc et clang :-/
J'ai pas trouvé comment avoir une approche similaire sans ça…

J'ai adoré cette mise en perspective historique d'un fait qui nous semble couler de source, alors qu'il ne l'a pas toujours été, semble-t-il.

Un grand merci à l'interviewer et l'interviewé, donc !

D'un point de vue outil, le support OpenMP implique :

1. du travail au niveau du front-end (parser les directives OpenMP, et les traduire en appels au runtime OpenMP)
2. du travail au niveau runtime (implémenter à la fois les symboles standardisés de la bililiothèque, et ceux générés par le front-end)
3. (optionnel, je suppose, mais c'est fait comme ça dans LLVM) modéliser la sémantique des symboles de la libomp, pour pouvoir optimiser certaines séquences

En te disant que tu es aussi cousin, je de sais pas moi, du Dalaï Lama, de Linus Torvald ou tout autre personne que tu apprécies ;-)

je remarque que si on incrémente C : C++ = D et qu'on retire C++ (donc D) du mot "module", on obtient "moule".

Une blague connexe : C++, ça augmente le C, mais ça renvoie toujours du C.

Journal très complet, très didactique. Il donne l'impression d'avoir tout compris, avec en plus un côté historique des plus agréable.

Super !

pas trop loin, en général j'aime bien le récupérer

J'ai ri :-)

Merci de nous partager ces détails d’implémentation, je trouve ça toujours fascinant.

Merci ! Je ne comprends pas la moitié des notions théoriques que je manipule, mais au moins j'essaie

il y a un présupposé que a est un entier

Oui, c'est un vrai problème qui doit cacher quelques bugs dans Pythran. Mais c'est ma technique secrète pour faire vivre le projet : introduire des bugs pour que les utilisateurs lèvent des issues, je les corrige et y a du mouvement :-)

Sinon, comment Pythran réalise-t-il l'exploration des fils que tu décris ? J'imagine que c'est à coup de graphe […]

C'est ça, le graphe contient le successeur de chaque nœud, et chaque nœud a un traitement dédié. On accumule (en calculant des unions d'intervalles) les résultats de chaque fil par nœud rencontré. Par contre je ne prends pas en compte les intervalles de vie des variables, j'explore comme une nouille à chaque fois. Si tu te sens de regarder ça, je suis preneur ;-)

Ahah, magie du français. J'émets des doutes sur le sujet, mais je les garde pour moi :-)
Sans trop prendre partie, on remarquera que la communauté s'est scindée entre ceux qui sont sur IRC, ceux qui sont sur Discord, et ceux qui sont sur les deux.

C'est bien une erreur, il fallait lire

-fpatchable-function-entry=N[,M=0] permet d'ajouter M (resp. N-M)

Si un modo peut faire le changement ?

Ce comportement est plutôt non-spécifié, ce qui est (heureusement) différent d'indéfini !

D'après un draft du standard pris au hasard, dans la section 3 Terms and definitions[intro.defs]

3.12[defns.impl.defined]implementation-defined behavior:
behavior, for a well-formed program construct and correct data, that depends on the implementation and that each implementation documents

3.27[defns.undefined]undefined behavior
behavior for which this document imposes no requirements

3.28[defns.unspecified]unspecified behavior
behavior, for a well-formed program construct and correct data, that depends on the implementation

On notera d'ailleurs l'élégant

3.14[defns.locale.specific]locale-specific behavior
behavior that depends on local conventions of nationality, culture, and language that each implementationdocuments

Je te propose cette légère amélioration :

int matrix_elements_sum_branchless_2(const std::vector<std::vector<int>>& matrix)
{
  const int row_size(matrix[0].size());
  std::vector<int> usable_column(row_size, -1);

  int result(0);

  for (const std::vector<int>& row : matrix)
    for (int i(0); i != row_size; ++i)
      {
        const int v(row[i]);
        result += v & usable_column[i];
        usable_column[i] &= v ? -1 : 0;
      }

  return result;
}

Elle a l'avantage de se vectoriser très bien, et d'éviter le passage par une multiplication. Elle reste moins bonne que la version de référence, sauf dans les cas dégénérés (pas de zéro p.e.). On notera qu'on pourrait aussi passer la boucle interne sous OpenMP :-)

Cas dégénéré : http://quick-bench.com/PTIzGKHuheFGyKEVjkAPBwgDo4s
Cas normal : http://quick-bench.com/goZHQlQ10U4sDqMiEP0nMyyXUBs

Merci pour ce petit jeu d'esprit !

Quelques liens attrapés à la volée pendant les présentations :

• GNU mes : https://www.gnu.org/software/mes/
• une réflexion sur l'installation de plusieurs version de libs en parallèle : https://ometer.com/parallel.html
• une phrase du packager de Guile qui m'a fait sourire : « dependencies must be as stable as you »
• les devs de lua jit qui se rendent compte que leur implem perso de memcmp est devenue pourrie
• le système de macro à la LISM de Nim est cool.
• le projet thoth part d'une idée délire qui m'a bien plu ! https://developers.redhat.com/blog/2019/10/28/microbenchmarks-for-ai-applications-using-red-hat-openshift-on-psi-in-project-thoth/project-thoth/

J'espère que ce petit défi vous a intéressé et appris de nouvelles choses sur python. Si vous voulez revoir d'autres défis du même type, n'hésitez pas à plussoyer ce journal et laisser des commentaires.

Très ludique, ça permet d'explorer, de découvrir des choses, j'<3

Premier indice, tiré de la doc mentionnée dans le journal :

A format_spec field can also include nested replacement fields within it.

Deuxième indice, lié à l'introspection :

w3m -dump -cols 1000 https://docs.python.org/3/reference/datamodel.html | grep __globals__ | head -n1

Tu explique que c'est plus simple de gérer python3 que python2+python3

Oui ^! Content que l'idée soit passée

Est-ce qu'il y avait des comportement complexes à implémenter avec python2 et qui sont grandement facilité dans python3 ?

Bien que cette question soit (à mon sens) vaine (Python3 est là, Python2 est mort, à quoi bon remuer le couteau dans la plaie), je peux donner un avis non éclairé. Pas de grosse simplification, dans la cadre de Pythran, plutôt de l'harmonisation et du cosmétique, à part la différenciation str/bytes qui ajoute de la complexité apparente à Python3. Je dis bien apparente car elle force au final à raisonner de manière plus précise sur nos données, et une fois ce travail fait, on est bien dans les clous, alors qu'en Python2 ça pouvait exploser sur le tard.

Ensuite Pythran a au final un usage assez simple de Python, donc n'est pas forcément représentatif.

Ah si, s'il fallait ralouiller un peu, je trouve les stacktrace Python2 plus lisibles que leur version Python3.