J'ai scotché quelques minutes en tête à tête avec ta doc, et soudain fiat lux !
En fait c'est quoi les iterator à la Sather ?
C'est l'idée que je définis une boucle, et qu'un message sur une classe integer va me permettre de définir le sous ensemble parcouru dans cette boucle.
C'est potentiellement très puissant, car ça évite de faire joujou avec un index à l'intérieur, et ça aide à la lecture du code parce qu'on comprend tout de suite ce qu'on fait.
Figure toi que j'ai implémenté ça en Lisaac (avec l'aide de Ben sur la fin) en Lisaac il y a quelques jours... Mais en plus puissant !
Le pb des parcours d'ensemble y est pas mal abordé.
Sather te permet de le faire, mais le problème est que tu es limité par les messages sur int (ceux avec le !), alors que le système qu'on a codé permet d'aller plus loin :
La méthode se trouve dans numeric :
- to upper:NUMERIC do action:BLOCK items func:BLOCK <-
ça s'utilise comment ?
1.to 7 do { i : NUMERIC;
//code
sum := sum + i;
} items { j:NUMERIC;
j.factorial
}
Dans cet exemple tu va sommer les factoriel (le i du premier bloc, prend le resultat de l'itérateur (j, qui va de 1 à 7) appliqué au deuxième), et ce qu'il y a de mieux par rapport à Sather, c'est que tu n'a pas besoin d'utiliser un message existant dans NUMERIC... Il te suffit de définir un BLOCK qui prend un int et t'en renvoi un. Et tu définis ce que tu veux
D'après ce que j'ai vu, ça apas été rajouté dans la dernière release (c'est un oubli), tu te le rajoute et tu pourras jouer avec :)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
C'est dans les cartons.
En fait, on aura carrément un système qui permettra de définir certaines optims de manière extren au compilateur, des sortes de fichiers de configuration.
Il faudra en écrire une par archi, ou on pourra mettre différentes choses :
- Taille de ligne de cache code et donnée
- Optimisation sur les entiers (mélange pipeline flottant et entier)
- Taille max de la mémoire
- etc...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Le fait que les professionnels de l'informatique ne connaissent rien au math, et plus généralement à la théorie est pour moi un gros problème.
Je travaille avec des gens qui ne connaissaient même pas les expressions régulières ou les tables de hashage. On leur donne pourtant des responsabilités et des projets de plusieurs milliers d'euros et de ligne de code à gérer.
Résultat, ils sont incapables de penser en terme de généricité, et passent leur temps à refaire, et à faire refaire (et c'est moi qui prend...) ce que l'on a déjà fait.
Pire, ceux qui ont eu affaire avec des théoriciens, les méprisent parce qu'ils "se souciaient plus de l'élégance que de l'efficacité".
Pour eux, théoricien = Type qui veut se faire plaisir avec des trucs qui coutent cher et qui ne marchent pas.
Ils ne voient pas au delà et ne comprennent pas que leur budget pourraient diminuer d'un tiers (et leur gains augmenter de tout autant) s'il était capable de voir un tout petit peu plus loin.
Le fait d'avoir un diplome d'ingénieur est mieux considéré que d'avoir fait une thèse en France est très symptomatique des oeillères des dirigeants dans le domaine...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
J'ai l'impression que c'est surtout un problème français.
En France, les ingénieurs pensent que les chercheurs sont des professeurs Nimbus qui ne servent à rien, et les chercheurs pensent que les ingénieurs sont des gros nuls à peine capable d'écrire un intranet en Java.
Résultat, t'as fait une thèse, ou même t'as un diplôme nul et t'as quelques papiers de recherches à ton actif, c'est mal vu quand tu cherches un boulot. C'est mon cas...
L'aspect mathématique, voire même théorique, est ainsi rejeté par les professionnels de l'industrie.
"Mathématique" c'est une notion, savoir ce qui rentre ou pas dans le champ d'une notion, n'est pas un débat sémantiquement profond, mais simplement un débat de sens, "que met-on dans telle ou ou telle catégorie ?"
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
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
[^] # Re: Sather
Posté par Ontologia (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 2.
En fait c'est quoi les iterator à la Sather ?
C'est l'idée que je définis une boucle, et qu'un message sur une classe integer va me permettre de définir le sous ensemble parcouru dans cette boucle.
C'est potentiellement très puissant, car ça évite de faire joujou avec un index à l'intérieur, et ça aide à la lecture du code parce qu'on comprend tout de suite ce qu'on fait.
Figure toi que j'ai implémenté ça en Lisaac (avec l'aide de Ben sur la fin) en Lisaac il y a quelques jours... Mais en plus puissant !
j'ai pensé à ça, après avoir lu et relu cette doc qui est géniale :
http://morpheus.cs.ucdavis.edu/papers/sweeny.pdf
Le pb des parcours d'ensemble y est pas mal abordé.
Sather te permet de le faire, mais le problème est que tu es limité par les messages sur int (ceux avec le !), alors que le système qu'on a codé permet d'aller plus loin :
La méthode se trouve dans numeric :
- to upper:NUMERIC do action:BLOCK items func:BLOCK <-
ça s'utilise comment ?
1.to 7 do { i : NUMERIC;
//code
sum := sum + i;
} items { j:NUMERIC;
j.factorial
}
Dans cet exemple tu va sommer les factoriel (le i du premier bloc, prend le resultat de l'itérateur (j, qui va de 1 à 7) appliqué au deuxième), et ce qu'il y a de mieux par rapport à Sather, c'est que tu n'a pas besoin d'utiliser un message existant dans NUMERIC... Il te suffit de définir un BLOCK qui prend un int et t'en renvoi un. Et tu définis ce que tu veux
D'après ce que j'ai vu, ça apas été rajouté dans la dernière release (c'est un oubli), tu te le rajoute et tu pourras jouer avec :)
« 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.
Cette lib sera celle d'IsaacOS, elle ne se repose que sur putPixel.
Mais on peut envisager des binding...
Il y a un générateur de binding pour Eiffel, qu'on pourra ensuite traduire en lisaac, on pourrait peut être l'utiliser ?
« 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.
En fait, on aura carrément un système qui permettra de définir certaines optims de manière extren au compilateur, des sortes de fichiers de configuration.
Il faudra en écrire une par archi, ou on pourra mettre différentes choses :
- Taille de ligne de cache code et donnée
- Optimisation sur les entiers (mélange pipeline flottant et entier)
- Taille max de la mémoire
- etc...
« 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.
http://isaacproject.u-strasbg.fr/API/index.html
Si tu l'as pas vu, c'est qu'on ne l'as pas assez mis en exergue :)
« 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.
Je travaille avec des gens qui ne connaissaient même pas les expressions régulières ou les tables de hashage. On leur donne pourtant des responsabilités et des projets de plusieurs milliers d'euros et de ligne de code à gérer.
Résultat, ils sont incapables de penser en terme de généricité, et passent leur temps à refaire, et à faire refaire (et c'est moi qui prend...) ce que l'on a déjà fait.
Pire, ceux qui ont eu affaire avec des théoriciens, les méprisent parce qu'ils "se souciaient plus de l'élégance que de l'efficacité".
Pour eux, théoricien = Type qui veut se faire plaisir avec des trucs qui coutent cher et qui ne marchent pas.
Ils ne voient pas au delà et ne comprennent pas que leur budget pourraient diminuer d'un tiers (et leur gains augmenter de tout autant) s'il était capable de voir un tout petit peu plus loin.
Le fait d'avoir un diplome d'ingénieur est mieux considéré que d'avoir fait une thèse en France est très symptomatique des oeillères des dirigeants dans le domaine...
« 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.
En France, les ingénieurs pensent que les chercheurs sont des professeurs Nimbus qui ne servent à rien, et les chercheurs pensent que les ingénieurs sont des gros nuls à peine capable d'écrire un intranet en Java.
Résultat, t'as fait une thèse, ou même t'as un diplôme nul et t'as quelques papiers de recherches à ton actif, c'est mal vu quand tu cherches un boulot. C'est mon cas...
L'aspect mathématique, voire même théorique, est ainsi rejeté par les professionnels de l'industrie.
"Mathématique" c'est une notion, savoir ce qui rentre ou pas dans le champ d'une notion, n'est pas un débat sémantiquement profond, mais simplement un débat de sens, "que met-on dans telle ou ou telle catégorie ?"
« 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