serge_sans_paille a écrit 269 commentaires

Les gains peuvent atteindre 100x.

J'ai regardé ton code (pas possible de reproduire les perfs, il me manque le fichier d'entrée et une valeur pour le nombre de round) et le gain de x100 n'est pas surprenant : double boucle imbriquée, le cas parfait pour les compilos statiques ;-)

Note que ça n'enlève rien aux mérites de condon hein, juste pour dire que c'est un point ou cPython ne brille pas et où tout compilateur pour Python devrait s'en sortir plutôt bien. Le support des générateurs et d'expression du style next(filter(lambda m: m[1], moves))[0] c'est chouette (et c'est aussi dans pythran bien sûr ;-))

Je trouve la liste des modules supportés plutôt respectable !

Bonne question! Si on regarde précisément le code sans passage par référence, on voit qu'une des deux récursions a été transformée en boucle, on peut imaginer une contrainte sur l'analyse d'aliasing ?

Vu dans les sources de condon:

from python import numpy as np # Codon will call NumPy through CPython's API

D'après https://docs.python.org/3/reference/executionmodel.html#resolution-of-names :

If a name binding operation occurs anywhere within a code block, all uses of the name within the block are treated as references to the current block. This can lead to errors when a name is used within a block before it is bound. This rule is subtle.

en gros on rentre dans le scope de la classe. Ce scope introduit une variable locale x et donc toute référence à x dans ce scope se fera en référançant la variable locale. Or lors de l'évaluation de la partie droite de l'assignation, x n'est pas encore assigné, bam NameError.

Merci pour ce retour personnel. Exactement ce que je cherchais :-)

Merci pour le partage ! C'est sympa l'idée de filtrer les commit suivant le bug id, et de les classifier en se basant sur les infos du bug.

Par contre ça fait d'énorme changelog. Ce n'est pas un mal hein, probablement un choix. On pourrait imaginer (je n'ai pas regardé si votre gestionnaire de bug permet de hiérarchiser ces derniers) de n'afficher que les bugs d'une certaine criticité... Merci en tout cas \o

Je partage largement ton point de vue. Il n'y a pas à ma conaissance d'entreprise derrière PyPI, c'est un projet communautaire, autant essayer d'améliorer l'existant ensemble, que chacun donne un peu du sien me semble plutôt normal.

Si tu as du temps à investir pkoa pas :-) Mais bon, il faudra probablement que tu aies aussi le temps d'aider à les corriger, à toi de voir ;-)

Pythran aurait tellement pu tomber dans n'importe lequel de ces soucis... je soupçonne que la suite de test explosera ;-)

Et bien à mon grand soulagement, oui. les seules choses qu'il a fallu faire ont été :

1. Prendre en compte le fait que sys.platform renvoie une valeur jusqu'alors non supportée
2. La fonction sincos se détecte différemment.

Pour le reste, il semblerait que Python soit suffisamment bien supporté sous cette plateforme, et que le code C++ généré par Pythran est suffisamment portable.

Ensuite je n'ai pas testé moi même, ni même lancé la suite de test. C'est juste un retour d'utilisateur satisfait une fois ces deux changements appliqués !

À mon tour de me montrer curieux : quel genre de galère rencontres-tu ?

Carrément ! Un clou de plus dans le cercueil de mes illusions.

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.