serge_sans_paille a écrit 250 commentaires

J'ai mesuré, on est de l'ordre de 10^-6 secondes pour l'import de typing

Tiens tiens, une connaissance, salut, ça fait plaisir :-)

C'est la solution que j'ai utilisée au final, mais ce n'est pas très satisfaisant intellectuellement. C'est du typage graduel quoi Gradual_typing.

Bien tenté ;-)

En l'absence d'indication, on peut aussi imaginer que les déclarations soient globales, ce qui rend l'ensemble nettement plus intéressant (à défaut d'être complètement utile) et produit le code suivant, même en -O3 (et à juste titre) (cf. https://godbolt.org/z/cYP6j1bsh)

d:
        .quad   a
        .zero   8
b:
        .zero   8
a:
        .zero   4

Finalement, la seule vraie difficulté du quizz est effectivement jetée aux oubliettes, bien joué !

Il n'y a pas d'undefined behavior dans l'exemple si la déclaration a été faite au niveau globale.

La déclaration suivante :

int (*(c(void)))[10]

se lit de l'intérieur vers l'extérieur, en spirale en commençant par le nom de la variable et en commençant à tourner par la droite (tout en mettant un doigt sur le nez et en prononçant très vite l'incantation kerniganetrichie).

La déclaration suivante est valide :

int (*(c(void)))[10] { return 0; }

Très sympathique, cette enquête. Et une prose agréable, merci pour le partage ! Quelques, pistes, qui ne te seront peut-être pas accessibles vu les versions du compilo utilisées :

• comme mentionné dans un autre commentaire, --gc-sections est un drapeau de l'éditeur de lien qui permet de dégager les symboles non référencés et non exportés, à combiner avec -ffunction-sections.

• à défaut, on peut utiliser un orderfile qui force un order entres les différents symboles, assurant une meilleur localité du code. On peut le générer par instrumentation, avec dtrace, où (avec un clang "trunk") depuis les informations de profiling

• en post-link, on peut réordonner les sections en utilisant les informations de profilage, p.e. avec Bolt.

Si le premier SIGUSR1 est géré avant réception du deuxième SIGUSR1, c'est ok, non ? EN tout cas c'est le comportement que j'observe…

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 :-)