Disons que j'ai réfléchis à ça depuis longtemps : transformer une équation mathématique en utilisant les vrais propriété des objets manipulés pour réduire l'équation entière par une des méthodes d'approximation, au lieu d'avoir 20 appels de fonctions. Je voulais le faire avec un pseudo-langage qui cible le C++, mais python vers C++, c'est encore mieux.
Le cas général étant très complexe, pour commencer, j'imagine que transformer une lib mathématique en template C++ à utiliser à la place d'appel de fonction devrait correctement fonctionner : c'est gcc qui fera le boulot. Cela revient à une sorte d'inlining de fonction.
Je ne connais pas python, donc, c'est difficile de m'y mettre. Par contre, je serais curieux de voir le résultat de compilation "typique" d'un cœur de boucle passé en C++.
Question bête est-ce que tu peux aller plus loin dans la compilation vers C++ ?
Je ne sais pas comment les fonctions mathématiques sont gérées en python, mais en C, math.h contient les définitions de code des fonctions usuels qui sont appelé par le code. Ces fonctions sont écrites avec des polynômes et des réductions de domaines.
Si ces fonctions étaient définit en template C++, et si tu génères des appels de template, le compilateur devrait pouvoir directement optimiser les opérations en les combinant (si présent dans la même unité de compilation).
A cause des restrictions de IEE754, Pythran aurait encore beaucoup de marge à faire l'optimisation lui-même. En gros, est-il possible de reprendre les définitions mathématiques des opérations lors de la génération de code, pour combiner ensuite le code généré. Cela ressemble au travail manuel qui est fait dans math.c pour chacune des opérations de base.
La réputation d'IBM est d'acheter des boites, puis de ne plus s'occuper des logiciels, juste de tirer parti de la base installée.
Cela remonte à quelques années, mais beaucoup de client utilisaient DOORS et tous s'en plaignaient.
J'imagine que tu parles, bien, sûr des compotes-bouchons, roi du gouter des enfants maltraités par leur parents qui ne veulent pas leur donner un paquet de cookies complet.
packagemainimport("io""log""net/http")funcmain(){// Hello world, the web serverhelloHandler:=func(whttp.ResponseWriter,req*http.Request){io.WriteString(w,"Hello, world!\n")}http.HandleFunc("/hello",helloHandler)log.Fatal(http.ListenAndServe(":8080",nil))}
C'est quoi plus dure "à évaluer" ? Soit c'est évaluable, soit cela ne l'est pas.
Tu sépares clairement la phase compilation de la phase exécution, mais dans beaucoup de langage, cela n'a pas trop de sens.
Par exemple, go est un langage compilé. Pourtant, en test, je fais un "go run" qui compile et exécute à la volé. Donc, que l’exécution de ta machine de turin se fasse à la compile ou à l’exécution, cela ne change pas grand chose d'un point de vue pratique (vu de l'extérieur).
Pour que cela fonctionne, il faut que le µP puisse intervenir sur le code/mémoire du cpu de management. Le grain de riz peut modifier un petit bout de l'ordinateur, mais il n'aura jamais la capacité de filtrer le contenu réseau pas exemple.
Il faudrait que le grain de riz soit connecté à un lien I2C ou SPI qui gère le cpu de management présent dans le chipset pour en programmer une partie.
Le cas d'usage typique que je vois, c'est une lib de regexp qui compile la regexp à la compilation et non explicitement en pseudo-code comme en C.
C'est de définir un DSL dont l'écriture d'un simple émulateur permet de le transformer en compilateur.
C'est la lecture de fichier externe, dans un autre langage (JSON, jpg) pour l'inclure dans le projet directement, pour éviter d'avoir à relire un fichier à coté du binaire à l’exécution.
Par exemple dans le cadre d'une simulation scientifique, ce n'est pas parce que tous les paramètres du modèles sont connus statiquement qu'il est souhaitable d'exécuter la simulation durant la compilation. Au contraire, cela peut être pratique de pouvoir sélectionner des bouts de codes qui doivent être évalués en premier et incorporés dans le reste du code de la simulation pour pouvoir être optimisé autant que possible.
On est d'accord que c'est un cas ultra-spécifique ? J'imagine bien le cas d'usage, le cas habituel de simulateur que j'ai vu est plutôt un modèle qui load des entrées depuis un fichier.
Dans Lisaac (paix à son ame), le hello world qui ouvrait une fenêtre graphique (genre alerte Javascript) faisait 12 ko. Donc, c'est possible de faire de la découpe. Un programme est un graph acyclique, cela aide à couper les bouts non utilisés.
Non, c'est vrai. Dans mon souvenir, le nouveau linker "Gold" de Gcc vire les objets ( au sens binaire) qui ne sont pas utilisés, comme une passe d'élimination de code mort mais au niveau assembleur.
Je suis d'accord que metaocaml a fait un gros effort d'unification du langage.
Mais il ne me semble pas qu'une lib metaocaml soit utilisable avec un code ocaml.
Je ne vois toujours pas pourquoi il est absolument nécessaire pour l'utilisateur d'indiquer tous les bouts de code à exécuter à la compilation, et ne pas le déduire de l'usage des constantes.
Le fait même de devoir utiliser un code spécifique empêche toute réutilisation du code "normal" pour son usage à la compilation.
Il y a des choses intéressantes qui sont faites dans ce domaine, et je trouve ça un peu triste d'ignorer une idée simplement parce que tu n'aimes pas la syntaxe. Si le sujet t'intéresse, tu devrais peut-être te renseigner sur ce que les gens ont déjà fait dessus.
Pourquoi crois-tu que je ne connais pas le sujet ? Je connaissais déjà metaocaml. Ce n'est pas qu'une histoire de syntaxe, mais de "langage dans le langage", de complexité inutile.
L'idée de la méta-programmation "staged" (étagée) est de laisser l'utilisateur définir ses propres évaluations partielles,
Oui, j'avais bien compris. Mais c'est inutile dans le cas général. Donc, à cause du cas particuliers, le truc définit quelques choses de + compliqué.
C'est facile à utiliser mais l'utilisateur ne peut pas contrôler la méthode de spécialisation.
Les widgets sont toujours présenté comme le moyen le plus évident de faire de l'objet. Pourtant, dans java FX pour éviter les arborescences horribles d'héritages, tous les objets sont des "nodes", et l'héritage est plat.
Si on regarde la technique du DOM virtuel (ELM, react,…), il s'agit toujours de créer un arbre d'objet avant de faire un diff avec l'existant avant de l'afficher. Ocaml gère très bien des arbres qui ne sont pas des objets au sens strict.
Il est vrai que cela dépend beaucoup des structures de données en "ligne" possible. Ocaml utilise beaucoup la liste chainé simple, elle pourrait avoir un traitement particuliers. Je pensais que la complexité venait de l'inexistence de syntaxe "statique" pour les conteneurs. Il n'y a pas d'équivalent à JSON ou aux structures de Perl en OCaml.
La voie alternative suivie par MetaOCaml est d'être très explicite sur les phases de la compilation.
De son côté le C++ a fait le choix de laisser le choix aux compilateurs la taille de la pile de récursion lors des calcul templates.
D'un coté on a une impossibilité théorique forte, de l'autre un choix pragmatique. D'un coté, on a un syntaxe incompréhensible, de l'autre une syntaxe moche sauf pour les cas simples et des lib ultra puissante. D'un coté, on a un outil quasiment pas utilisé même dans la communauté ocaml et de l'autre le langage qui doit avoir le plus de ligne de code écrite, et qui est encore dans le top5 des langages utilisées malgré son age.
Bref, le fait de mettre une limite de temps de compilation est une fonctionnalité très rationnelle, sachant qu'une compilation infinie est forcément une erreur.
C'est vrai que les linker devrait faire un plus gros effort pour nettoyer le code inutile.
Mais leur conception date de l'époque, ou les machines étaient tellement faible que la compilation se faisait fichier par fichier, et donc le programme final de link devait faire le minimum de travail. Aujourd'hui ce découpage n'a aucun sens.
[^] # Re: Expliciter l'intérêt
Posté par Nicolas Boulay . En réponse au journal Pythran - 0.9.0 - kozhamzer. Évalué à 3 (+0/-0).
Disons que j'ai réfléchis à ça depuis longtemps : transformer une équation mathématique en utilisant les vrais propriété des objets manipulés pour réduire l'équation entière par une des méthodes d'approximation, au lieu d'avoir 20 appels de fonctions. Je voulais le faire avec un pseudo-langage qui cible le C++, mais python vers C++, c'est encore mieux.
Le cas général étant très complexe, pour commencer, j'imagine que transformer une lib mathématique en template C++ à utiliser à la place d'appel de fonction devrait correctement fonctionner : c'est gcc qui fera le boulot. Cela revient à une sorte d'inlining de fonction.
Je ne connais pas python, donc, c'est difficile de m'y mettre. Par contre, je serais curieux de voir le résultat de compilation "typique" d'un cœur de boucle passé en C++.
"La première sécurité est la liberté"
[^] # Re: Expliciter l'intérêt
Posté par Nicolas Boulay . En réponse au journal Pythran - 0.9.0 - kozhamzer. Évalué à 3 (+0/-0).
Question bête est-ce que tu peux aller plus loin dans la compilation vers C++ ?
Je ne sais pas comment les fonctions mathématiques sont gérées en python, mais en C, math.h contient les définitions de code des fonctions usuels qui sont appelé par le code. Ces fonctions sont écrites avec des polynômes et des réductions de domaines.
Si ces fonctions étaient définit en template C++, et si tu génères des appels de template, le compilateur devrait pouvoir directement optimiser les opérations en les combinant (si présent dans la même unité de compilation).
A cause des restrictions de IEE754, Pythran aurait encore beaucoup de marge à faire l'optimisation lui-même. En gros, est-il possible de reprendre les définitions mathématiques des opérations lors de la génération de code, pour combiner ensuite le code généré. Cela ressemble au travail manuel qui est fait dans math.c pour chacune des opérations de base.
"La première sécurité est la liberté"
[^] # Re: Microsoft en rêvait
Posté par Nicolas Boulay . En réponse au journal IBM achète Red Hat. Évalué à 7 (+4/-0).
La réputation d'IBM est d'acheter des boites, puis de ne plus s'occuper des logiciels, juste de tirer parti de la base installée.
Cela remonte à quelques années, mais beaucoup de client utilisaient DOORS et tous s'en plaignaient.
"La première sécurité est la liberté"
[^] # Re: Complices
Posté par Nicolas Boulay . En réponse à la dépêche Nos oignons, retours sur 2017-2018 et campagne de dons. Évalué à 3 (+1/-1).
Les droits ne sont pas là pour faire joli. On dirait que tu es pour la théorie et contre l'effectivité du droit.
qu'est-ce que cela change ?!
"La première sécurité est la liberté"
# Compote en gourde ?
Posté par Nicolas Boulay . En réponse au journal La compote de pommes en gourde n'est PAS un truc de fainéant.. Évalué à 10 (+9/-0).
J'imagine que tu parles, bien, sûr des compotes-bouchons, roi du gouter des enfants maltraités par leur parents qui ne veulent pas leur donner un paquet de cookies complet.
"La première sécurité est la liberté"
# Y'a Assistance dans le nom
Posté par Nicolas Boulay . En réponse au journal Le VAE n'est PAS un truc de fainéant. Évalué à 7 (+5/-1).
Un truc où il y a marqué "Assistance" dans le nom est forcément un truc de fainéant.
C'est bien connu que tous les assistés sont des fainéant, non ?
CQFD.
Moto électrique à assistance humaine écologique, cela pète plus.
"La première sécurité est la liberté"
[^] # Re: go
Posté par Nicolas Boulay . En réponse au journal Réduire la taille des exécutables générés avec PyInstaller. Évalué à 3 (+0/-0).
Go n'a presque pas de dépendance. Le binaire de base fait quand même 7 Mo (runtime).
"La première sécurité est la liberté"
[^] # Re: Cutelyst
Posté par Nicolas Boulay . En réponse au journal Des nouvelles d'Ulfius, framework web en C. Évalué à 8 (+6/-1). Dernière modification le 10/10/18 à 11:16.
En Go, le hello world http c'est :
"La première sécurité est la liberté"
[^] # Re: À boire et à manger
Posté par Nicolas Boulay . En réponse au journal Un développeur qui dénonce. Évalué à 3 (+0/-0).
C'est quoi plus dure "à évaluer" ? Soit c'est évaluable, soit cela ne l'est pas.
Tu sépares clairement la phase compilation de la phase exécution, mais dans beaucoup de langage, cela n'a pas trop de sens.
Par exemple, go est un langage compilé. Pourtant, en test, je fais un "go run" qui compile et exécute à la volé. Donc, que l’exécution de ta machine de turin se fasse à la compile ou à l’exécution, cela ne change pas grand chose d'un point de vue pratique (vu de l'extérieur).
"La première sécurité est la liberté"
[^] # Re: C'était mieux avant
Posté par Nicolas Boulay . En réponse au journal Un développeur qui dénonce. Évalué à 5 (+2/-0).
Bizarre, pour moi la régulation thermique était une protection du bios de la machine, pas de l'OS.
"La première sécurité est la liberté"
[^] # Re: ajouter des puces à un PCB = fantasme
Posté par Nicolas Boulay . En réponse au journal Des puces-espionnes installées sur des cartes mères par les Chinois ?. Évalué à 4 (+1/-0).
Pour que cela fonctionne, il faut que le µP puisse intervenir sur le code/mémoire du cpu de management. Le grain de riz peut modifier un petit bout de l'ordinateur, mais il n'aura jamais la capacité de filtrer le contenu réseau pas exemple.
"La première sécurité est la liberté"
[^] # Re: Taille de la puce
Posté par Nicolas Boulay . En réponse au journal Des puces-espionnes installées sur des cartes mères par les Chinois ?. Évalué à 6 (+3/-0).
Il faudrait que le grain de riz soit connecté à un lien I2C ou SPI qui gère le cpu de management présent dans le chipset pour en programmer une partie.
Pourquoi pas ?
"La première sécurité est la liberté"
[^] # Re: À boire et à manger
Posté par Nicolas Boulay . En réponse au journal Un développeur qui dénonce. Évalué à 3 (+0/-0).
Quel différence tu fais ? Le linker de Gcc cherche les objets non appelés pour les éliminer du code;
"La première sécurité est la liberté"
[^] # Re: optimisation et propagation de constante
Posté par Nicolas Boulay . En réponse à la dépêche OCaml 4.06 et 4.07. Évalué à 4 (+1/-0).
On dirait qu'il fait ce dont je parlais plus haut : une syntaxe particulière pour le call à faire à la compilation.
"La première sécurité est la liberté"
[^] # Re: optimisation et propagation de constante
Posté par Nicolas Boulay . En réponse à la dépêche OCaml 4.06 et 4.07. Évalué à 3 (+0/-0).
Je ne comprend pas ce que fais ce code Lisp. C'est un parseur de regexp ?
"La première sécurité est la liberté"
[^] # Re: optimisation et propagation de constante
Posté par Nicolas Boulay . En réponse à la dépêche OCaml 4.06 et 4.07. Évalué à 3 (+0/-0).
Tu peux aussi avoir l'inverse, et une syntaxe de sémantique de "call" qui l'interdit à la compilation, pour ton cas spécifique.
C'est bizarre d'utiliser ocaml pour de la simulation numérique, non ? Il me semble que ocaml n'utilise ni openMP ni le code SSE vectoriel.
"La première sécurité est la liberté"
[^] # Re: optimisation et propagation de constante
Posté par Nicolas Boulay . En réponse à la dépêche OCaml 4.06 et 4.07. Évalué à 3 (+0/-0).
Le cas d'usage typique que je vois, c'est une lib de regexp qui compile la regexp à la compilation et non explicitement en pseudo-code comme en C.
C'est de définir un DSL dont l'écriture d'un simple émulateur permet de le transformer en compilateur.
C'est la lecture de fichier externe, dans un autre langage (JSON, jpg) pour l'inclure dans le projet directement, pour éviter d'avoir à relire un fichier à coté du binaire à l’exécution.
"La première sécurité est la liberté"
[^] # Re: optimisation et propagation de constante
Posté par Nicolas Boulay . En réponse à la dépêche OCaml 4.06 et 4.07. Évalué à 3 (+0/-0).
On est d'accord que c'est un cas ultra-spécifique ? J'imagine bien le cas d'usage, le cas habituel de simulateur que j'ai vu est plutôt un modèle qui load des entrées depuis un fichier.
"La première sécurité est la liberté"
[^] # Re: À boire et à manger
Posté par Nicolas Boulay . En réponse au journal Un développeur qui dénonce. Évalué à 5 (+2/-0).
Dans Lisaac (paix à son ame), le hello world qui ouvrait une fenêtre graphique (genre alerte Javascript) faisait 12 ko. Donc, c'est possible de faire de la découpe. Un programme est un graph acyclique, cela aide à couper les bouts non utilisés.
"La première sécurité est la liberté"
[^] # Re: À boire et à manger
Posté par Nicolas Boulay . En réponse au journal Un développeur qui dénonce. Évalué à 4 (+1/-0).
Non, c'est vrai. Dans mon souvenir, le nouveau linker "Gold" de Gcc vire les objets ( au sens binaire) qui ne sont pas utilisés, comme une passe d'élimination de code mort mais au niveau assembleur.
"La première sécurité est la liberté"
[^] # Re: optimisation et propagation de constante
Posté par Nicolas Boulay . En réponse à la dépêche OCaml 4.06 et 4.07. Évalué à 4 (+1/-0).
Je suis d'accord que metaocaml a fait un gros effort d'unification du langage.
Mais il ne me semble pas qu'une lib metaocaml soit utilisable avec un code ocaml.
Je ne vois toujours pas pourquoi il est absolument nécessaire pour l'utilisateur d'indiquer tous les bouts de code à exécuter à la compilation, et ne pas le déduire de l'usage des constantes.
Le fait même de devoir utiliser un code spécifique empêche toute réutilisation du code "normal" pour son usage à la compilation.
"La première sécurité est la liberté"
[^] # Re: optimisation et propagation de constante
Posté par Nicolas Boulay . En réponse à la dépêche OCaml 4.06 et 4.07. Évalué à 4 (+1/-0).
Pourquoi crois-tu que je ne connais pas le sujet ? Je connaissais déjà metaocaml. Ce n'est pas qu'une histoire de syntaxe, mais de "langage dans le langage", de complexité inutile.
Oui, j'avais bien compris. Mais c'est inutile dans le cas général. Donc, à cause du cas particuliers, le truc définit quelques choses de + compliqué.
Dans quel cas, cela a un intérêt pour lui ?
"La première sécurité est la liberté"
[^] # Re: On peut mélanger les trois paradigmes mais...
Posté par Nicolas Boulay . En réponse à la dépêche OCaml 4.06 et 4.07. Évalué à 3 (+0/-0).
Les widgets sont toujours présenté comme le moyen le plus évident de faire de l'objet. Pourtant, dans java FX pour éviter les arborescences horribles d'héritages, tous les objets sont des "nodes", et l'héritage est plat.
Si on regarde la technique du DOM virtuel (ELM, react,…), il s'agit toujours de créer un arbre d'objet avant de faire un diff avec l'existant avant de l'afficher. Ocaml gère très bien des arbres qui ne sont pas des objets au sens strict.
"La première sécurité est la liberté"
[^] # Re: optimisation et propagation de constante
Posté par Nicolas Boulay . En réponse à la dépêche OCaml 4.06 et 4.07. Évalué à 4 (+1/-0).
Il est vrai que cela dépend beaucoup des structures de données en "ligne" possible. Ocaml utilise beaucoup la liste chainé simple, elle pourrait avoir un traitement particuliers. Je pensais que la complexité venait de l'inexistence de syntaxe "statique" pour les conteneurs. Il n'y a pas d'équivalent à JSON ou aux structures de Perl en OCaml.
D'un coté on a une impossibilité théorique forte, de l'autre un choix pragmatique. D'un coté, on a un syntaxe incompréhensible, de l'autre une syntaxe moche sauf pour les cas simples et des lib ultra puissante. D'un coté, on a un outil quasiment pas utilisé même dans la communauté ocaml et de l'autre le langage qui doit avoir le plus de ligne de code écrite, et qui est encore dans le top5 des langages utilisées malgré son age.
Bref, le fait de mettre une limite de temps de compilation est une fonctionnalité très rationnelle, sachant qu'une compilation infinie est forcément une erreur.
"La première sécurité est la liberté"
[^] # Re: À boire et à manger
Posté par Nicolas Boulay . En réponse au journal Un développeur qui dénonce. Évalué à 3 (+1/-1).
C'est vrai que les linker devrait faire un plus gros effort pour nettoyer le code inutile.
Mais leur conception date de l'époque, ou les machines étaient tellement faible que la compilation se faisait fichier par fichier, et donc le programme final de link devait faire le minimum de travail. Aujourd'hui ce découpage n'a aucun sens.
"La première sécurité est la liberté"