Merci à toi de partager quelques instants de ton quotidien avec nous, de démystifier l'activité de recherche et montrer à quoi « ça sert » puisque l'on vit dans un monde où la finalité semble importante à beaucoup :-/
Quelques questions ! Tu dis que ta communauté est en contact avec celle qui poussent des langages comme Julia. Concrètement, comment se passent vos échanges, sur quels types de questions vous penchez vous etc ? Êtes-vous en contact avec la communauté LLVM pour aller vers des transformations prouvées, faire évoluer l'IR etc ?
Et tu n'as pas parlé d'une partie qui me semble prendre de plus en plus de temps dans le monde académique : la recherche de financement. Est-ce parce que l'INRIA est protecteur de ce point de vue, parce que c'est une partie négligeable dans ton cas, autre ?
Encore merci pour l'effort de vulgarisation et de partage !
Un grand merci pour ce journal passionnant, mêlant passion, code et humanisme. Je ne sais pas trop comment exprimer ça mais il se dégage de ce journal un ton de calme sérénité admirable. Ça donne envie !
Si un modérateur passe dans le coin : il manque un s à scientifique dans le titre, et dans la note de bas de page numéro 1, il faut remplacer chines par chiens sinon c'est moins drôle.
Qu'est-ce qui compile le plus vite ? gperf + le compilateur C, ou le code en C++ ?
Aucune idée. Je driais gperf +C intuitivement.
Qu'est-ce que tu entends exactement par le fait que olaf est moins robuste ?
C'est un bonhomme de neige, alors il fond :-)
En vrai, cette fonction de hash a de forte chance de toujours donner des collisions, donc elle est pas assez générique (j'aurais du écrire générique plutôt que robuste)
Comme en en C ou en C++, sans surprises, d'après la doc http://llvm.org/docs/LangRef.html#lshr-instruction
If op2 is (statically or dynamically) equal to or larger than the number of bits in op1, the result is undefined. Donc undefined behavior
Quand je lis la doc du projet, je ne vois aucune mention de typage statique, ça me fait plutôt penser à l'approche de Nuitka qui transforme n'importe quel code Python en programme C++ qui appelle le runtime CPython. Là ils ont ré-implem le runtime CPython il me semble, mais l'idée est la même.
D'une certaine façon, ça ressemble aussi à Pyston avec le JIT en moins.
Assez loin de Pythran finalement, puisqu'ils visent une approche générique, pas un embeded Domain Specifc Language, un langage spécialisé pour le calcul scientifique embarqué dans Python.
Sinon le fait de se concentrer sur Python2.7 (même choix que Pyston !) est discutable. On a mis plusieurs mois à supporter Python3 dans Pythran après avoir fait ce choix, je les plains :-)
Elle est compilée avec des drapeaux qui permettent la vectorisation, mais après avoir inspecté le binaire, gcc a pas réussi à vectoriser, non. Du coup ça veut dire que la version pythran a encore un soucis, mais je n'ai pas encore trouvé lequel :-)
car j'avais vraiment besoin de classes
C'est dans ma TODO liste, tiens tu attendrais quoi comme annotation #pythran export pour une classe ? C'est pas bien fixé pour moi…
Oui, c'est le leïtmotiv de Pythran : obtenir les performances d'un code compilé (pour ce que ça peut vouloir dire) et optimisé, sans avoir à descendre le niveau d'abstraction.
Je pense que c'est aussi un problème d'API, ou plutôt de compromis API/perf.
Prenons le cas de GMP, il est chouette. Tu as trois entiers multi-précision ab et c. Tu veux calculer rapidement a + b * c. Tu peux demander à l'utilisateur d'écrire (et ce le cas en C d'ailleurs), mpz_mul(tmp, b, c); mpz_add(out, a, tmp). Le problème c'est que (en plus d'être verbeux) tu introduis un temporaire, et que peut-être qu'il existe une façon de faire un fused multiply add plus efficacement qu'en le cassant en une multiplication et une addition, comme pour la boucle que tu cites où la fusion de boucle a permis, entre autres, de ne pas parcourir deux fois les tableaux. Et tu ne peux pas te permettre d'écrire toutes les fonction add_muladd_add_mul` etc pour chaque optimisation possible.
Les expression templates en général permettent de résoudre les deux soucis : au niveau API, l'utilisateur écris juste a + b * c et au niveau perf la machinerie (souvent bien plus complexe que ce qui est présentée ici, et bien mieux faite aussi) se charge de l'évaluation efficace de l'expression.
Et tu as raison, l'évaluation paresseuse fait parti des effets de bord sympa ;-)
[^] # Re: Lisibilité
Posté par serge_sans_paille (site web personnel) . En réponse au journal Jouons avec le ``switch`` et C++17. Évalué à 3.
L(e seul) avantage du deuxième, c'est que tu peux augmenter le nombre d'éléments du switch à volonté, sans avoir à spawner les copier-coller :-)
[^] # Re: Namespace bits ?
Posté par serge_sans_paille (site web personnel) . En réponse au journal Jouons avec le ``switch`` et C++17. Évalué à 2.
C'est ça !
# Passionant
Posté par serge_sans_paille (site web personnel) . En réponse au journal La recherche en langages de programmation au quotidien. Évalué à 10.
Merci à toi de partager quelques instants de ton quotidien avec nous, de démystifier l'activité de recherche et montrer à quoi « ça sert » puisque l'on vit dans un monde où la finalité semble importante à beaucoup :-/
Quelques questions ! Tu dis que ta communauté est en contact avec celle qui poussent des langages comme Julia. Concrètement, comment se passent vos échanges, sur quels types de questions vous penchez vous etc ? Êtes-vous en contact avec la communauté LLVM pour aller vers des transformations prouvées, faire évoluer l'IR etc ?
Et tu n'as pas parlé d'une partie qui me semble prendre de plus en plus de temps dans le monde académique : la recherche de financement. Est-ce parce que l'INRIA est protecteur de ce point de vue, parce que c'est une partie négligeable dans ton cas, autre ?
Encore merci pour l'effort de vulgarisation et de partage !
[^] # Re: Chieur de service
Posté par serge_sans_paille (site web personnel) . En réponse au journal Cinelerra, openshot video et kdenlive, le duel. Évalué à 8.
Et pour éviter les problèmes de genre, ont parle aussi d'une truelle !
[^] # Re: UN BIZUTH !
Posté par serge_sans_paille (site web personnel) . En réponse au journal [liens] Mais juste un. Évalué à 2.
Ou un Bizu :-)
[^] # Re: Existe-t-il des compilateurs C/C++ qui donnent une sémantique à tous les programmes ?
Posté par serge_sans_paille (site web personnel) . En réponse au journal Compilateur trop intelligent. Évalué à 3.
Pour un
rol
portable et efficace, il y a : https://blog.regehr.org/archives/1063 !cf https://godbolt.org/g/TQchFT
[^] # Re: pypy
Posté par serge_sans_paille (site web personnel) . En réponse au journal Formation à Lyon : Compilateurs pour le Python Scientifique. Évalué à 2.
@freejef, pour Lille, je te laisse voir avec l'organisateur.
# Trugarez
Posté par serge_sans_paille (site web personnel) . En réponse au journal Comment je suis devenu chef de projet. Évalué à 10. Dernière modification le 08 octobre 2017 à 21:48.
Un grand merci pour ce journal passionnant, mêlant passion, code et humanisme. Je ne sais pas trop comment exprimer ça mais il se dégage de ce journal un ton de calme sérénité admirable. Ça donne envie !
Oh, et merci de m'avoir fait découvrir le Principe de subsidiarité !
[^] # Re: un temps d'exécution multiplié par 0.76
Posté par serge_sans_paille (site web personnel) . En réponse au journal Pythran 0.8.2 — compilation de noyaux scientifiques écrits en Python. Évalué à 3.
Si l'original prend 1s, le nouveau temps est de 0.76s. Ça prend moins de temps, ça va plus vite.
# Typos
Posté par serge_sans_paille (site web personnel) . En réponse au journal Pythran 0.8.2 — compilation de noyaux scientifiques écrits en Python. Évalué à 3.
Si un modérateur passe dans le coin : il manque un s à scientifique dans le titre, et dans la note de bas de page numéro 1, il faut remplacer chines par chiens sinon c'est moins drôle.
[^] # Re: Numpy FTW
Posté par serge_sans_paille (site web personnel) . En réponse au journal Un Python qui rivalise avec du C++. Évalué à 6.
Merci pour ton journal qui m'a motivé à ajouter le support Pythran pour ce paquet ! La PR débarquera sous peu :-)
# Cython inside
Posté par serge_sans_paille (site web personnel) . En réponse au journal Un Python qui rivalise avec du C++. Évalué à 10.
lu dans le README
Donc triche :-) Ce n'est plus du Python mais un langage hybride…
[^] # Re: Temps de compilation
Posté par serge_sans_paille (site web personnel) . En réponse au journal Frozen - Une alternative à gperf pour les utilisateurs de C++14 fan de constexpr. Évalué à 5.
Aucune idée. Je driais
gperf +C
intuitivement.C'est un bonhomme de neige, alors il fond :-)
En vrai, cette fonction de hash a de forte chance de toujours donner des collisions, donc elle est pas assez générique (j'aurais du écrire générique plutôt que robuste)
# en LLVM
Posté par serge_sans_paille (site web personnel) . En réponse au journal Un décalage de 64 bits, ça vous inspire comment ?. Évalué à 4.
Comme en en C ou en C++, sans surprises, d'après la doc http://llvm.org/docs/LangRef.html#lshr-instruction
Donc undefined behaviorIf op2 is (statically or dynamically) equal to or larger than the number of bits in op1, the result is undefined.
[^] # Re: Module et type abstrait
Posté par serge_sans_paille (site web personnel) . En réponse au journal Une petite histoire d'utilisation type fort dans Ocaml. Évalué à 6.
j'ai ri :-)
# Concurent de Nuitka plutôt non ?
Posté par serge_sans_paille (site web personnel) . En réponse au journal Grumpy : un nouveau concurrent à pythran. Évalué à 7.
Quand je lis la doc du projet, je ne vois aucune mention de typage statique, ça me fait plutôt penser à l'approche de Nuitka qui transforme n'importe quel code Python en programme C++ qui appelle le runtime CPython. Là ils ont ré-implem le runtime CPython il me semble, mais l'idée est la même.
D'une certaine façon, ça ressemble aussi à Pyston avec le JIT en moins.
Assez loin de Pythran finalement, puisqu'ils visent une approche générique, pas un embeded Domain Specifc Language, un langage spécialisé pour le calcul scientifique embarqué dans Python.
Sinon le fait de se concentrer sur Python2.7 (même choix que Pyston !) est discutable. On a mis plusieurs mois à supporter Python3 dans Pythran après avoir fait ce choix, je les plains :-)
[^] # Re: SIMD
Posté par serge_sans_paille (site web personnel) . En réponse au journal Pythran chatouille Cython. Évalué à 3.
Elle est compilée avec des drapeaux qui permettent la vectorisation, mais après avoir inspecté le binaire, gcc a pas réussi à vectoriser, non. Du coup ça veut dire que la version pythran a encore un soucis, mais je n'ai pas encore trouvé lequel :-)
C'est dans ma TODO liste, tiens tu attendrais quoi comme annotation
#pythran export
pour une classe ? C'est pas bien fixé pour moi…[^] # Re: Temps d'exécution sans optimisation ?
Posté par serge_sans_paille (site web personnel) . En réponse au journal Pythran chatouille Cython. Évalué à 4.
Il y a un état de fai[tl] : la demande est là. Il suffit de regarder les compilos existants :
Et chacun de ces compilos a pour objectif principal ou auxiliaire mais en tout cas affiché d'optimiser du code Python utilisant numpy :-)
[^] # Re: Temps d'exécution sans optimisation ?
Posté par serge_sans_paille (site web personnel) . En réponse au journal Pythran chatouille Cython. Évalué à 3.
Oui, c'est le leïtmotiv de Pythran : obtenir les performances d'un code compilé (pour ce que ça peut vouloir dire) et optimisé, sans avoir à descendre le niveau d'abstraction.
[^] # Re: Temps d'exécution sans optimisation ?
Posté par serge_sans_paille (site web personnel) . En réponse au journal Pythran chatouille Cython. Évalué à 8.
CPython pur :
c'est ultra lent :-)
# Using the force, Luke
Posté par serge_sans_paille (site web personnel) . En réponse à la dépêche Concours « jeu de mots » et cadeaux pour Noël. Évalué à 10.
sous CC BY-SA 4
# Coquille
Posté par serge_sans_paille (site web personnel) . En réponse à la dépêche C++17 fixe l’ordre d’évaluation des expressions. Évalué à 1.
Je pense que c'est c’est f() avant h() (sequenced before)
Sinon excellent journal, le dessin m'a bien fait marrer !
[^] # Re: Pas uniquement string
Posté par serge_sans_paille (site web personnel) . En réponse au journal Switch, chaîne constante et c++. Évalué à 1.
Passionnant ! Merci !
[^] # Re: Plusieurs remarques
Posté par serge_sans_paille (site web personnel) . En réponse au journal Switch, chaîne constante et c++. Évalué à 9.
Tout à fait d'accord avec toi; C'est même écrit dans le journal :-/
[…] on aurait pu éviter de fournir une implem miteuse
Tout à fait d'accord avec toi; C'est même écrit dans le journal :-/
Et pour les chagrins qui veulent du code dans leur case: on peut utiliser une std::function
Avec un code qui illustre ça
[^] # Re: Avantage ?
Posté par serge_sans_paille (site web personnel) . En réponse au journal [C++14 ] Expressions template pour les nuls. Évalué à 3. Dernière modification le 31 mai 2016 à 13:46.
Je pense que c'est aussi un problème d'API, ou plutôt de compromis API/perf.
Prenons le cas de GMP, il est chouette. Tu as trois entiers multi-précision
a
b
etc
. Tu veux calculer rapidementa + b * c
. Tu peux demander à l'utilisateur d'écrire (et ce le cas en C d'ailleurs),mpz_mul(tmp, b, c); mpz_add(out, a, tmp)
. Le problème c'est que (en plus d'être verbeux) tu introduis un temporaire, et que peut-être qu'il existe une façon de faire un fused multiply add plus efficacement qu'en le cassant en une multiplication et une addition, comme pour la boucle que tu cites où la fusion de boucle a permis, entre autres, de ne pas parcourir deux fois les tableaux. Et tu ne peux pas te permettre d'écrire toutes les fonctionadd_mul
add_add_mul` etc pour chaque optimisation possible.Les expression templates en général permettent de résoudre les deux soucis : au niveau API, l'utilisateur écris juste
a + b * c
et au niveau perf la machinerie (souvent bien plus complexe que ce qui est présentée ici, et bien mieux faite aussi) se charge de l'évaluation efficace de l'expression.Et tu as raison, l'évaluation paresseuse fait parti des effets de bord sympa ;-)