serge_sans_paille a écrit 257 commentaires

La lib rust utilise des fonction interne du compilo, par ce que des choses sont pas possible.

c'est beaucoup le cas pour la bibliothèque standard C++ également

C'était bien ça. Juste un petit bonbon syntaxique sans prétention :-)

>>> class a(*{++a},a=a--a): {}

template void foo(T) = delete;

Punaise ! Ça je ne connaissais pas dans ce cadre là, uniquement sur des fonctions membres. C'est super intéressant, merci  iniment. C++11 en plus.

Python n'étant pas vraiment un langage compilé (bien qu'il y ait une étape de compilation avant l'exécution hein), il était hors jeux.

En fait ma remarque fait écho à une intuition courante comme quoi « si on retire un #include et que ça compile toujours, alors cet include est inutile ». Un corollaire de mon example est que non.

Dison qu'on a pas le même bon sens.

je viens de relire le journal, et à aucun moment il ne mentionne l'avis de l'auteur :-)

C'est vrai qu'on pourrait avoir une fonction constexpr qui prend les chaines en entrées et renvoie un tableau initialisé et les offsets, ce serait plus maintenable :-)

Petite fierté personelle : krita utilise xsimd depuis https://github.com/KDE/krita/commit/70863966699379856e7fa08d0d8fc2aee4342c29 pour la vectorisation de certains algos. Le commentaire du commit fait chaud au coeur :

This brings Arm support to our backend for Free(tm).

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é !