Forcément un langage type statiquement n'a pas les qualités d'un langage dynamiquement, il n'en a pas le défauts non plus (cf.. pyprotocols, pychecker, test sur les types d'arguments, ...)
Et vu les innombrables trolls sur le sujet sur la toile on ne peut guère être categorique.
Lisaac est fortement typé, ce n'est pas un langage à typage dynamique, attention :-)
En revanche ca m'aurait plus de savoir dans quelle catégorie se placait Lisaac en lisant la dépêche parce que perso, le fait qu'il optimise l'arbre de décision du programme ca m'apporte pas grand chose.
Bref j'aurais aimé du concret, une vraie comparaison avec un langage comme Java et Ruby plûtôt qu'une liste complète de concepts que seul une minorité connait (enfin je crois).
Par exemple la curryfication et la tail recursion, c'est quoi ? peut on vivre sans ?
Pour les contrats , tu as à disposition des librairies qui s'en chargent et il n'y a guère de languages hormis Eiffel qui l'intègrents nativement. Est-ce le cas de Lisaac ?
C'est vrai que j'ai été un peu trop conceptuel.
La curryfication c'est le fait de transformer par exemple une fonction de 2 paramètre, en fonction de fonction, comme ça si tu as un paramètre tu le renvoi à la premiere et ça te renvoi une fonction. curryfication
L'intérêt des contrats en Eiffel et lisaac (parce qu'il y en a vraiment en lisaac), c'est que tes contrats sont hérités : ils suivent l'arbre d'héritage, ce qui fait que tu peux les ajouter en comlpétant cet arbre.
Ya des mots clé dans le langage, en Lisaac, le mot clé Old te permet de comparer l'ancienne valeur d'une variable en début de fonction et à la fin.
Ce que comble la programmation aspect c'est une des faiblesses du modèle objet (à proptotypes ou non). Elle prend en charge les problématiques transverses qui auparavant etaient disséminées et vise justement à alléger et rendre encore plus réutilsable ces briques de base.
Elle se veut donc complémentaire. et on ne peut pas dire qu'elllees n'evoluent pas.
Lisaac n'est donc pas objet ?
Perso, mais ce n'est que mon avis, je trouve ça bidouille, l'AOP..
ça revient à quoi en fait ?
ça revient à mettre des goto conditionnels dans ton code.
Je faisais ça en Basic quand j'étais gosse...
'fin cela dit tu pourras le faire sur des variables en lisaac : tu met un print dans le contrat de ta variable, ça va t'afficher le print à chaque fois qu'on accèdera à la variable (et testera le contrat, en passant)..
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Qu'est-ce qui te semble absolument indispensable comme Framework ?
Car lorsque je regarde Java (std) je trouve
(les question signifie que je ne sais pas, pas que je critique)
- une lib pour faire des interfaces utilisateur (1)
- de quoi gérer des fichiers, des flux, de la sérialisation d'objet par ce biais... (1)
- Reflexivité (2)
- threading (3)
- réseau (4)
- RMI (2)
- Securité (5)
- SQL (5) mais ça devrait pas être méchant. Surtout que ce sera surement intégré ds le langage.
- text (5) ah oui c'est pas con, faudrai le faire ça. On a toutes les briques de base en +
- Collection, on a
- libZIP, à coder
- accessibility ( c'est quoi ?)
- activity ( c'est quoi ?)
- imageio, ya un début avec BITMAP, etc...
- javax.management (sert à quoi ?)
- Xml (4) et je vais personnellement l'améliorer pour en faire une lib de rêve, car je connais très bien le sujet...
(1) On l'a, elle est pas aussi complète, mais elle va grossir
(2) C'est prévu (1 an ou 2)
(3) Pas besoin on a le modèle COP
(4) La lib Eiffel va nous l'apporter
(5) là effectivement, on a rien
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Lisaac génère pour le moment du C. Il peut très bien, dans le futur, générer toutes sortes de chose : byteCode Java, ou code Java à compiler. ByteCode LLVM, etc...
Le compilateur possède un petit langage interne avec quelques primitives qui donne lieu à génération du code. On pourrait imaginer d'avoir un jour différents back-end, c'est tout à fait envisageable.
Java est arrivé je pense au bon moment, s'est servi de la niche de l'applet web pour conquérir l'espace et a bénéficié d'une grosse librairie et d'un bon framework n-tiers.
Sans compter le marketing de SUN derrière.
Notre marketing à nous, c'est le libre :-)
La grosse lib... on va avoir celle d'Eiffel bientôt, ce qui amènera un minimum vital pour coder (regexp, opengl, xml, réseau) et surtout écrire des libs plus haut niveau.
J'établi à l'heure actuelle une liste comparative (Java / Eiffel / Lisaac) afin de déterminer les priorités.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Je souffre énormément en Java à cause de l'inexistance de BLOCK.
En effet, avec ce type (qui est une fonction en fait), et la syntaxe à mot clé , on peut inventer les structures de controle qu'on veut.
Ainsi dans la lib standard, j'ai rajouté différents foreach :
foreach_while : Parcours tous les éléments et continu tant que la condition sur l'élément est vrai. ça évite de faire une construction hyper lourde à la java, avec un while, un tmp, un cast, et tout le toutim
foreach_until : même idée, avec le until
Ma préférée est le
- to up: INTEGER do action:BLOCK items function:BLOCK <-
Qui se trouvera dans numeric.
Bref, les langages qui m'impose de subir les desiderata des concepteurs pour les structures de contrôle, ça m'emmerde.
Il est vrai que parvenir à modifier la lib standard n'est pas anodin (il faut que l'idée soit bonne, la tester sous toutes les coutures, que Benoit Sonntag soit d'accord), mais au moins c'est possible de le faire.
Dans cette étude http://morpheus.cs.ucdavis.edu/papers/sweeny.pdf , il est expliqué que beaucoup de problèmes (bugs, etc...) proviennent de parcours d'index dans des tableaux et de compréhension d'ensemble.
C'est une fonction dans laquelle tu défini une fonction de parcours d'ensemble.
1. to n do { i : INTEGER;
// code
} items { j : INTEGER;
2*j+1
};
je rajoute cela à ce qu'a pointé Tramo Piere, et effectivement, Java est un vieux langage dépassé. Et comme disais je ne sais plus qui, ici même
"Java : une syntaxe bas niveau avec les inconvéniants du haut niveau"
C# même combat.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Je suis d'accord avec ce que vient de dire nicO, mais c'est vrai qu'on est peut être allé un peu vite en le mettant dans le subversion : GNA impose que le logiciel soit libre, ce qui est effectivement illégal.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Pour ce qui est de la gestion de la mémoire, à mon avis, une bonne partie de la différence de prformance viens de la. Mes programmes travail sur des volumes de données assez énormes, l'un d'entre eux ayant des pics à 15 Go en C, le même dépassant les 21 Go en Lisaac. Et la machine sur laquelle il tourne dispose de 16 Go de ram, le deuxième doit donc swapper de temps en temps pendant l'éxecution.
Pour le moment, Lisaac prend ses aises niveau mémoire, mais ça va s'améliorer, ya des idées en l'air comme la réutilisation de variables locales, en jouant sur les lignes de cache (oui parce que la gestion de la mémoire en lisaac essaye de jouer sur la gestion de ligne de cache)
Comme on veut cibler l'embarqué, on va travailler sur la consommation mémoire, mais c'était pas la priorité pour cette version.
Pour ce qui est des déroulements de boucles, c'est plustôt au compilateur de le faire. (éventuellement via un -funroll-loop) La version en C n'a aucun déroulement manuel pas plus que la version en Lisaac. Le problème c'est que ce genre de manip rend vite le code illisible et impossible à maintenir pour un gain qui au final est minimime par rapport à ce que le compilateur produit.
C'est prévu.
Pour ce qui est de l'inniling du message en dessous, il est déjà configurer mais je ne sais plus à combien, je n'ai pas le makefile sous les yeux mais je pourrais vérifié. La taille du code ayant peu d'importance ici, l'essentiel est de trouver le bon compromis avec la taille du cache. J'avais fait pas mal d'essais pour voir à quel point on pouvais inliner sans que les caches miss fassent perdre plus qu'on ne gagne. Le problème c'est que tout les petits reglages dans ce genre on été faits pour la version en C et ne sont surement pas adapters à la version en Lisaac.
Tu parles du cache code ou du cache données ?
En ce qui concerne le cache code, il faut effectivement faire attention à ne pas trop inliner.
En ce qui concerne le cache données, Lisaac gère tant que possible la mémoire en se basant sur des lignes de cache à 64 octets, mais c'est encore très perfectible.
Ya aussi une grosse optim qui est prévu et qui fera gagner beaucoup, c'est de sortir les variables.
Dans le C généré par lisaac, tu as souvent :
while( cond) {
((int *)struct1->struct2->struct3)[index ] = ...
...
}
Le pb c'est que gcc recalcul le pointeur à chaque fois ds la boucle, faut donc créer une variable locale (ou mieux utilser une existante) qui va le faire avant le début du while, et éviter ça.
Benoit évalue cette optim à deux semaine de travail.
J'ai fait cette optim à la main sur du code critique en calcul, j'ai gagné 15%
Et je te parle pas de la futur autovectorisation de GCC, de mélanger flottant et entier, etc...
Ya encore énormément de chose à faire en optim, on est qu'au tout début.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Il faut que tu joue avec le switch i du compilateur. Il règle le niveau d'inlining. Par défaut, il est à 20 il me semble. 0 permet d'avoir un code assez petit, 30 ou 40 est en général ce qu'on trouve de mieux pour les perfs.
Résumé, pour les perfs compile avec :
lisaac monfichier.li -i30 -O
Normalement, tu devrais grapiller quelques %
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
C'est d'ailleurs la raison pour laquelle la plupart des langages de recherche ne percent pas : parce que leurs concepteurs pensent qu'un langage de programmation doit s'apparenter à un langage formel décrivant des objets mathématiques.
Ce qui n'est pas le cas pour Lisaac.
Il est certes très minimaliste, mais pas à but mathématique.
Benoit Sonntag l'a certes pensé en tant que chercheur, mais aussi en tant qu'auteur de logiciel généraliste : il a été demo-coder, il a écrit un logiciel de dessin vectoriel, etc...
C'est vraiment un langage qui a été conçu pour faire de tout.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Merci pour tes remarques concernant l'install, on va en prendre bonne note.
Je me demandais : As-tu compilé le c produit par lisaac, avec les mêmes optimisation que ton source initial en C ?
genre :
-O3 -fomit-frame-pointer -ftree-vectorize -msse -march=pentium4 -mtune=pentium4
Ensuite, il suffit d'optimiser l'algorithme pour avoir des performances, la gestion mémoire n'est pas à ta charge. Par contre utiliser des variables temporelles, des déroulement de boucles peuvent aider.
Mais nicO saurait mieux répondre que moi sur le sujet :)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
et je suis sûr que c'est un type qui allait à la messe, pour ensuite dessiner ses couvertures dégoulinantes de bon sentiments, comme les comédies musicales...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Pas à ma connaissance car ça n'a pas été publié (y compris pour Lisaac, mais ça va venir).
Google m'a trouvé un petit doc écrit par Xavier Leroy (ocaml)
ça explique en gros le principe. http://pauillac.inria.fr/~xleroy/dea/compil/flow
L'analyse de flot en Lisaac a pour mission de déterminer le type vivant d'un objet en fonction des diverses possibilités d'exécution du code.
Cela permet d'éviter les switch sur type dans le code.
Le compilateur arrive à retomber, à 96 % sur du code monomorphique (un seul type possible), et utilise une table dichotomique pour le reste .
En ce qui concerne pypy, je ne sais pas, il va falloir que j'analyse la chose, mais ce doit être plus difficile de compiler un langage non typé, car le compilateur doit sérieusement mouliner pour typer son flot..
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
J'avais récemment le cas d'une classe contenant plein de CString, que j'ajoutait dans un CArray. Dans une boucle, je faisais régulièrement un new de cette classe que j'ajoutait ensuite au CArray. je me retrouvais ensuite avec une collection du même pointeur (le dernier ajouté).
Les spécialistes du C++ dans la boite ont conclu à un bug du compilateur (VC98).
A la décharge de krosoft (dont le dernier logiciel dépourvu de bug que j'ai connu était le BASIC 128 sur TO9), C++ est un langage horrible(ment complexe) et ça doit pas être facile.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Et si il existait un framework web genre RoR, incluant en natif la gestion des cubes, permettant de travailler directement avec le langage MDX, suffisament performant...
Ca pourrait aider ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
D'ailleurs c'est par le succès relatif de RoR malgré la vague AJAX/Web2 que l'on peut être amener à douter que la communauté du Libre soit à même de proposer une alternative crédible - surtout si elle n'est pas l'initiatrice mais doit plutôt courir après - du fait que les moyens financiers sont beaucoup plus importants et donc nettement plus déterminants qu'il y a quelques années.
Je me pose quelques questions au sujet de RoR qui à l'air assez fantatisque, surtout que je ne connais pas les concurents proposés par Adobe et MS.
Pourquoi RoR reste assez confidentiel ?
- Peut être parce que l'infrastructure serveur est assez complexe : en production il faut allier Apache et Mongrel, le mod_ruby posant quelques problèmes parait-il
- Jeunesse de l'application qui n'est stable que depuis 2004, soit moins de 3 ans, cela fait peu, et il faut bien voir que 3 ans pour former des compétences c'est peu. Voir des entreprises se lancer dans le développement de logiciels entiers utilisant ce framework, quand pas mal d'entre elles imposent celui-ci (souvent Java, pour être sûr de pouvoir repasser derrière à coup sûr) cela prend du tout. L'effet boule de neige est lent à démarrer au début.
- La lenteur : Selon le Shootout (bon ça vaut ce que ça vaut), Ruby est 3 fois plus que PHP qui est lui même 10 fois plus lent que Java ! Ca dissuade dans un contexte ou l'on essaye de faire des économie d'électricité dans les salles serveur, lorsque les problèmes de gestion de la climatisation restent problématiques. Et dans un contexte multi-coeur, Ruby est-il facilement multi-thread ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Packaging pour distributions ?
Posté par Ontologia (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 2.
Comme 0.12 qui tend vers la spécification 0.2
Ya un schéma ici : http://isaacproject.u-strasbg.fr/li/li_download.html
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Mouais
Posté par Ontologia (site web personnel) . En réponse au journal Excel 2007 c'est super. Évalué à 2.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: sonntag
Posté par Ontologia (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 2.
Et vu les innombrables trolls sur le sujet sur la toile on ne peut guère être categorique.
Lisaac est fortement typé, ce n'est pas un langage à typage dynamique, attention :-)
En revanche ca m'aurait plus de savoir dans quelle catégorie se placait Lisaac en lisant la dépêche parce que perso, le fait qu'il optimise l'arbre de décision du programme ca m'apporte pas grand chose.
Bref j'aurais aimé du concret, une vraie comparaison avec un langage comme Java et Ruby plûtôt qu'une liste complète de concepts que seul une minorité connait (enfin je crois).
Par exemple la curryfication et la tail recursion, c'est quoi ? peut on vivre sans ?
Pour les contrats , tu as à disposition des librairies qui s'en chargent et il n'y a guère de languages hormis Eiffel qui l'intègrents nativement. Est-ce le cas de Lisaac ?
C'est vrai que j'ai été un peu trop conceptuel.
La curryfication c'est le fait de transformer par exemple une fonction de 2 paramètre, en fonction de fonction, comme ça si tu as un paramètre tu le renvoi à la premiere et ça te renvoi une fonction.
curryfication
L'intérêt des contrats en Eiffel et lisaac (parce qu'il y en a vraiment en lisaac), c'est que tes contrats sont hérités : ils suivent l'arbre d'héritage, ce qui fait que tu peux les ajouter en comlpétant cet arbre.
Ya des mots clé dans le langage, en Lisaac, le mot clé Old te permet de comparer l'ancienne valeur d'une variable en début de fonction et à la fin.
Ce que comble la programmation aspect c'est une des faiblesses du modèle objet (à proptotypes ou non). Elle prend en charge les problématiques transverses qui auparavant etaient disséminées et vise justement à alléger et rendre encore plus réutilsable ces briques de base.
Elle se veut donc complémentaire. et on ne peut pas dire qu'elllees n'evoluent pas.
Lisaac n'est donc pas objet ?
Perso, mais ce n'est que mon avis, je trouve ça bidouille, l'AOP..
ça revient à quoi en fait ?
ça revient à mettre des goto conditionnels dans ton code.
Je faisais ça en Basic quand j'étais gosse...
'fin cela dit tu pourras le faire sur des variables en lisaac : tu met un print dans le contrat de ta variable, ça va t'afficher le print à chaque fois qu'on accèdera à la variable (et testera le contrat, en passant)..
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: sonntag
Posté par Ontologia (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 2.
Car lorsque je regarde Java (std) je trouve
(les question signifie que je ne sais pas, pas que je critique)
- une lib pour faire des interfaces utilisateur (1)
- de quoi gérer des fichiers, des flux, de la sérialisation d'objet par ce biais... (1)
- Reflexivité (2)
- threading (3)
- réseau (4)
- RMI (2)
- Securité (5)
- SQL (5) mais ça devrait pas être méchant. Surtout que ce sera surement intégré ds le langage.
- text (5) ah oui c'est pas con, faudrai le faire ça. On a toutes les briques de base en +
- Collection, on a
- libZIP, à coder
- accessibility ( c'est quoi ?)
- activity ( c'est quoi ?)
- imageio, ya un début avec BITMAP, etc...
- javax.management (sert à quoi ?)
- Xml (4) et je vais personnellement l'améliorer pour en faire une lib de rêve, car je connais très bien le sujet...
(1) On l'a, elle est pas aussi complète, mais elle va grossir
(2) C'est prévu (1 an ou 2)
(3) Pas besoin on a le modèle COP
(4) La lib Eiffel va nous l'apporter
(5) là effectivement, on a rien
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par Ontologia (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 2.
Lisaac génère pour le moment du C. Il peut très bien, dans le futur, générer toutes sortes de chose : byteCode Java, ou code Java à compiler. ByteCode LLVM, etc...
Le compilateur possède un petit langage interne avec quelques primitives qui donne lieu à génération du code. On pourrait imaginer d'avoir un jour différents back-end, c'est tout à fait envisageable.
Java est arrivé je pense au bon moment, s'est servi de la niche de l'applet web pour conquérir l'espace et a bénéficié d'une grosse librairie et d'un bon framework n-tiers.
Sans compter le marketing de SUN derrière.
Notre marketing à nous, c'est le libre :-)
La grosse lib... on va avoir celle d'Eiffel bientôt, ce qui amènera un minimum vital pour coder (regexp, opengl, xml, réseau) et surtout écrire des libs plus haut niveau.
J'établi à l'heure actuelle une liste comparative (Java / Eiffel / Lisaac) afin de déterminer les priorités.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: sonntag
Posté par Ontologia (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 2.
Je souffre énormément en Java à cause de l'inexistance de BLOCK.
En effet, avec ce type (qui est une fonction en fait), et la syntaxe à mot clé , on peut inventer les structures de controle qu'on veut.
Ainsi dans la lib standard, j'ai rajouté différents foreach :
foreach_while : Parcours tous les éléments et continu tant que la condition sur l'élément est vrai. ça évite de faire une construction hyper lourde à la java, avec un while, un tmp, un cast, et tout le toutim
foreach_until : même idée, avec le until
Ma préférée est le
- to up: INTEGER do action:BLOCK items function:BLOCK <-
Qui se trouvera dans numeric.
Bref, les langages qui m'impose de subir les desiderata des concepteurs pour les structures de contrôle, ça m'emmerde.
Il est vrai que parvenir à modifier la lib standard n'est pas anodin (il faut que l'idée soit bonne, la tester sous toutes les coutures, que Benoit Sonntag soit d'accord), mais au moins c'est possible de le faire.
Dans cette étude http://morpheus.cs.ucdavis.edu/papers/sweeny.pdf , il est expliqué que beaucoup de problèmes (bugs, etc...) proviennent de parcours d'index dans des tableaux et de compréhension d'ensemble.
C'est une fonction dans laquelle tu défini une fonction de parcours d'ensemble.
1. to n do { i : INTEGER;
// code
} items { j : INTEGER;
2*j+1
};
je rajoute cela à ce qu'a pointé Tramo Piere, et effectivement, Java est un vieux langage dépassé. Et comme disais je ne sais plus qui, ici même
"Java : une syntaxe bas niveau avec les inconvéniants du haut niveau"
C# même combat.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Benchmark
Posté par Ontologia (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 1.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: sonntag
Posté par Ontologia (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 5.
Pour le moment, Lisaac prend ses aises niveau mémoire, mais ça va s'améliorer, ya des idées en l'air comme la réutilisation de variables locales, en jouant sur les lignes de cache (oui parce que la gestion de la mémoire en lisaac essaye de jouer sur la gestion de ligne de cache)
Comme on veut cibler l'embarqué, on va travailler sur la consommation mémoire, mais c'était pas la priorité pour cette version.
Pour ce qui est des déroulements de boucles, c'est plustôt au compilateur de le faire. (éventuellement via un -funroll-loop) La version en C n'a aucun déroulement manuel pas plus que la version en Lisaac. Le problème c'est que ce genre de manip rend vite le code illisible et impossible à maintenir pour un gain qui au final est minimime par rapport à ce que le compilateur produit.
C'est prévu.
Pour ce qui est de l'inniling du message en dessous, il est déjà configurer mais je ne sais plus à combien, je n'ai pas le makefile sous les yeux mais je pourrais vérifié. La taille du code ayant peu d'importance ici, l'essentiel est de trouver le bon compromis avec la taille du cache. J'avais fait pas mal d'essais pour voir à quel point on pouvais inliner sans que les caches miss fassent perdre plus qu'on ne gagne. Le problème c'est que tout les petits reglages dans ce genre on été faits pour la version en C et ne sont surement pas adapters à la version en Lisaac.
Tu parles du cache code ou du cache données ?
En ce qui concerne le cache code, il faut effectivement faire attention à ne pas trop inliner.
En ce qui concerne le cache données, Lisaac gère tant que possible la mémoire en se basant sur des lignes de cache à 64 octets, mais c'est encore très perfectible.
Ya aussi une grosse optim qui est prévu et qui fera gagner beaucoup, c'est de sortir les variables.
Dans le C généré par lisaac, tu as souvent :
while( cond) {
((int *)struct1->struct2->struct3)[index ] = ...
...
}
Le pb c'est que gcc recalcul le pointeur à chaque fois ds la boucle, faut donc créer une variable locale (ou mieux utilser une existante) qui va le faire avant le début du while, et éviter ça.
Benoit évalue cette optim à deux semaine de travail.
J'ai fait cette optim à la main sur du code critique en calcul, j'ai gagné 15%
Et je te parle pas de la futur autovectorisation de GCC, de mélanger flottant et entier, etc...
Ya encore énormément de chose à faire en optim, on est qu'au tout début.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Benchmark
Posté par Ontologia (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 2.
Tu y trouveras le SVN du projet.
Il y est.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: sonntag
Posté par Ontologia (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 2.
Il faut que tu joue avec le switch i du compilateur. Il règle le niveau d'inlining. Par défaut, il est à 20 il me semble. 0 permet d'avoir un code assez petit, 30 ou 40 est en général ce qu'on trouve de mieux pour les perfs.
Résumé, pour les perfs compile avec :
lisaac monfichier.li -i30 -O
Normalement, tu devrais grapiller quelques %
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Vaccination
Posté par Ontologia (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 3.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: sonntag
Posté par Ontologia (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 4.
Ce qui n'est pas le cas pour Lisaac.
Il est certes très minimaliste, mais pas à but mathématique.
Benoit Sonntag l'a certes pensé en tant que chercheur, mais aussi en tant qu'auteur de logiciel généraliste : il a été demo-coder, il a écrit un logiciel de dessin vectoriel, etc...
C'est vraiment un langage qui a été conçu pour faire de tout.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: sonntag
Posté par Ontologia (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 3.
Je me demandais : As-tu compilé le c produit par lisaac, avec les mêmes optimisation que ton source initial en C ?
genre :
-O3 -fomit-frame-pointer -ftree-vectorize -msse -march=pentium4 -mtune=pentium4
Ensuite, il suffit d'optimiser l'algorithme pour avoir des performances, la gestion mémoire n'est pas à ta charge. Par contre utiliser des variables temporelles, des déroulement de boucles peuvent aider.
Mais nicO saurait mieux répondre que moi sur le sujet :)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Il manque Martine et le dessinateur pédoque
Posté par Ontologia (site web personnel) . En réponse au journal Martine ou la vraie vie. Évalué à -2.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: sonntag
Posté par Ontologia (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 3.
Slashdot, ça passe pas, évidemment.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Vaccination
Posté par Ontologia (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 3.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: sonntag
Posté par Ontologia (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 2.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par Ontologia (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 4.
Google m'a trouvé un petit doc écrit par Xavier Leroy (ocaml)
ça explique en gros le principe.
http://pauillac.inria.fr/~xleroy/dea/compil/flow
L'analyse de flot en Lisaac a pour mission de déterminer le type vivant d'un objet en fonction des diverses possibilités d'exécution du code.
Cela permet d'éviter les switch sur type dans le code.
Le compilateur arrive à retomber, à 96 % sur du code monomorphique (un seul type possible), et utilise une table dichotomique pour le reste .
Tu trouveras des explications dans les slides ici : http://isaacproject.u-strasbg.fr/download/workshop.pdf
En ce qui concerne pypy, je ne sais pas, il va falloir que j'analyse la chose, mais ce doit être plus difficile de compiler un langage non typé, car le compilateur doit sérieusement mouliner pour typer son flot..
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Sather
Posté par Ontologia (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 3.
Espérons que la masse critique soit suffisante pour que cela serve à quelques chose...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: parser ?
Posté par Ontologia (site web personnel) . En réponse au message [expression régulière] détecter un caractère non espace dans une séquence.. Évalué à 2.
Super, j'y avais pas pensé, mais je sais pas comment l'écrire
l'inversion c'est avec '^' non ?
donc ^(\s{10})
le problème est que ça signifie début de ligne, 10 espaces.
Et si je fais
[^\s]{10} ça veut dire : tout caractère sauf \s sur 10 caractères.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: parser ?
Posté par Ontologia (site web personnel) . En réponse au message [expression régulière] détecter un caractère non espace dans une séquence.. Évalué à 2.
Je me suis mal exprimé...
Mon problème : j'ai une zone d'exactement n caractères, n fixé à l'avance, dans une chaine texte. Cette zone peut contenir n'importe quel caractère.
Je cherche une regexp qui match uniquement s'il y a au moins un caractère non espace (un \S) quelque part (je sais pas où...) dans les 10 caractères.
Donc si j'ai
' ' ça matche pas, mais si j'ai
' * ' ça matche
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Re:
Posté par Ontologia (site web personnel) . En réponse au journal Fin de gcc dans les *BSD ?. Évalué à 5.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Re:
Posté par Ontologia (site web personnel) . En réponse au journal Fin de gcc dans les *BSD ?. Évalué à 1.
Les spécialistes du C++ dans la boite ont conclu à un bug du compilateur (VC98).
A la décharge de krosoft (dont le dernier logiciel dépourvu de bug que j'ai connu était le BASIC 128 sur TO9), C++ est un langage horrible(ment complexe) et ça doit pas être facile.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Question stupide
Posté par Ontologia (site web personnel) . En réponse au journal apache perd du terrain face à IIS de manière inquiétante. Évalué à 2.
Ca pourrait aider ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Ror : Plusieurs hypothèses
Posté par Ontologia (site web personnel) . En réponse au journal apache perd du terrain face à IIS de manière inquiétante. Évalué à 3.
Je me pose quelques questions au sujet de RoR qui à l'air assez fantatisque, surtout que je ne connais pas les concurents proposés par Adobe et MS.
Pourquoi RoR reste assez confidentiel ?
- Peut être parce que l'infrastructure serveur est assez complexe : en production il faut allier Apache et Mongrel, le mod_ruby posant quelques problèmes parait-il
- Jeunesse de l'application qui n'est stable que depuis 2004, soit moins de 3 ans, cela fait peu, et il faut bien voir que 3 ans pour former des compétences c'est peu. Voir des entreprises se lancer dans le développement de logiciels entiers utilisant ce framework, quand pas mal d'entre elles imposent celui-ci (souvent Java, pour être sûr de pouvoir repasser derrière à coup sûr) cela prend du tout. L'effet boule de neige est lent à démarrer au début.
- La lenteur : Selon le Shootout (bon ça vaut ce que ça vaut), Ruby est 3 fois plus que PHP qui est lui même 10 fois plus lent que Java ! Ca dissuade dans un contexte ou l'on essaye de faire des économie d'électricité dans les salles serveur, lorsque les problèmes de gestion de la climatisation restent problématiques. Et dans un contexte multi-coeur, Ruby est-il facilement multi-thread ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker