serge_sans_paille a écrit 251 commentaires

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.

Suggestion de lecture de ton commentaire, qui à défaut de te rendre le moral, pourrait te faire sentir moins seul : n'est ce pas la tendance générale de notre société ? La communication plutôt que l'action ? Le paraître plutôt que l'être ? La forme plus que le fond ?

En tout cas, avoir d'autres centres d'intérêt que l'informatique permet d'aborder 2020 plus sereinement !

Dans la même veine

>>> 'weak' > 'strong'
True

Ahhh quel monde idéal :-)

Cela un sens d'avoir un AST de haut niveau pour faire des optims de haut niveau et ensuite de générer le C++ ?

C'est ce qu'on fait et oui ça a un sens : on fait les optims qui ont du sens au niveau Python, et qui seraient infaisable à un plus bas niveau (ou du moins plus dures à prouver, soyons modestes). Et on délègue le reste au compilo, qui fait lui aussi des optims à son niveau (p.e. la copy elision etc) et ensuite le compilateur, disons clang, génère de l'IR LLVM et encore d'autres optimisations arrivent. N'est-ce pas fantastique ? ;-)

pour l'IR LLVM, elle est de très bas niveau par rapport à ce qu'on veut faire, et surtout il n'y a pas de types paramétrés, alors que ceux ci sont au coeur de Pythran (pythran travaille sur des fonctions python polymorphes, génères des fonction c++ polymorphiques (template) et c'est à la toute fin que les annotations sont prises en compte. Ainsi on peut traduire du code python en C++, et l'embarquer dans une appli native.

Oui, je me demandais si tu parlais de types optionnels au sens de Option Type ou au sens de types que l'on peut ajouter de façon optionnelle. Cela semble être le second point.

Pythran pourrait utiliser ces types, mais comme ils sont optionnels, il doit surtout savoir faire sans :-) Et dans ce cas, autant faire sans !

L'intérêt serait serait pourtant de bénéficier de l'inférence / vérification de type par mypy, idéalement en en faisant une dépendance de Pythran…

L'ownership, c'est le suivi du cycle de vie de la mémoire ?

Dans mon jargon, oui :-) Pour le moment tous les types non scalaires passent par un shared_ptr, on doit pouvoir supprimer ça dans pas mal de cas !

Il s'agit de fonction de base à rendre vectorielle en C++ ?

oui

On a fait ça en partie : suppression de l'assignation de tuple, des lambda, des fonctions imbriquées… on pourrait effectivement aller encore plus loin dans ce sens, je partage ton point de vue sur les effets bénéfiques de l'approche. Quand à la recherche d'un « point bas » on fait ça aussi, avec une limite sur le nombre d'itérations quand même !

Je pense avoir vu une présentation de Lisaac aux journées de la compilation françaises, à Aussois. Probablement donnée par toi ?

Les fondements théoriques de Pythran sont assez flous et mouvants, mais il reste des choses amusantes à faire, soit au niveau du typage si c'est un truc qui te branche, ou également (mais c'est un gros chantier) sur l'ownership.

Plus humblement, certaines fonctions de pythonic gagneraient à avoir une version vectorielle, ça peut être un bon sujet pour commencer !