Lisaac n'arrivera jamais à ce niveau d'optim. Il fait simplement un meilleur boulot sur un code propre que gcc. Si tu commences à optimiser à mort un code C, c'est un peu comme si tu recodais en assembleur.
Je ne vois pas trop le problème en fait ? Je sais que c'est une des raisons qui fait que Linus haie le c++ (de la gestion mémoire derrière son dos) mais je ne sais pas trop les détails.
Fondamentalement qu'est-ce qui gène ? Le fait que d'habitude, on ne sais pas quand toute la mémoire sera pleine, ce qui empèche de bien tout utiliser ?
Je ne connais plus les chiffres de vente des µp 16 bits et des petits 32 bits arm. Je crois que l'on est pas loin du milliards. C'est sans commune mesure avec un téléphone ou autre.
Tu annonce 30 et 170KB, cela ne fait pas beaucoup sauf que les µP 16 bits on difficilement plus de 64KB de mémoire.
pour le bytcode, certe pour mettre sur la pile, tu utilies un mot d'un octet, et minimum 2 octets pour du x86, mais si tu fais une addition entre 2 nombres ailleurs dans la pile, sur x86, cela prendra toujours 2 octets mais combien en byte code java pour manipuler la pile et mettre les valeurs au bon endroit ?
Concernant la mise à jour de code, tu peux tout à fait patcher du binaire. Il n'y a pas vraiment de différence. La difficulté sera toujours la même : comment gérer les données des classes modifiés.
Puisque vous dites que vous ciblez l'embarqué, certains equipements necessitent une mise-a-jour logicielle. Il y a clairement un avantage a utiliser un langage produisant du ByteCode pour effectuer ces mises-a-jour
euh... HEIN. Il est fou. On se fait chier à produire du code rapide pour avoir la plateforme moins chère possible et il veut mettre une VM ?!
Du bytecode pour l'embarqué, c'est la meilleur de l'année. Surtout pour des mises à jour, c'est encore pire. (ps:je ne vois pas bien le rapport)
Ca s'est bien amélioré mais ca ne l'a pas empéché d'avoir percé.
Java misait sur une autre approche que Lisaac : sa lib pour gagner du temps.
Agressif ? Bof, pas plus que le commentaire noté +10 de Benoît Sonntag qui dit à 2 reprises que C# et Java sont des langages qui n'auraient jamais dû existé (sans aucune argumentation) quand Lisaac est "moderne".
On troll contre 2 langages et tu te sens tellement personnelement visé qu'il faut que tu attaques ?!
"vous avez rien compris avec vos technos de merde, voilà Lisaac, et encore, c'est qu'un début, vous allez voir !",
D'un point de vue purement langage (et non library), Effel ou OCaml sont bien supérieur à java ou c#.
La modularité facilite le déploiement, la maintenance, le partage de code, la souplesse de configuration et de personnalisation, etc.
Sauf que tu mélanges tout. Lisaac est purement objet (dans l'os même le pixel est un objet, et cela ne rame pas !). Tu as donc toutes la réutilisabilité du code, la personnalisation, et la configuration que tu veux. Pour l'instant, il n'y a pas encore de partage de _binaire_ possible. Mais, c'est juste la 1er version...
les algos d'optimisation spécifiques à Lisaac ne sont pertinents que dans les cas ou on fait l'impasse sur ces atouts de la modularité
J'aurais tendance à dire "t'es con ou tu le fais expres". Qu'est-ce qui empèche de faire une optimisation global d'une lib ? Une lib cela peut être aussi énorme ! Un compilo C ne fait des optims que fichiers C par fichier C, il ne va pas plus loin. Lisaac permet ici d'aller plus loin.
où l'on se contente de faire de l'héritage "pour faire joli" au sein d'un même module.
euh... comment dire .... On te dit que Lisaac gère meme l'héritage alimentaire... l'héritage d'implémentation quoi, pas de concept/type. Justement pour faire plus propre que d'habitude... A part ça on troll...
Sinon, ne le prennez pas mal, mais j'ai l'impression que vous vous focalisez un peu trop sur les performances par rapport au C. Ce n'est pas un mal en soit, mais il y a d'autres aspects a prendre en compte, comme la maintenance ou la facilité d'apprentissage.
C'est évidement pris en compte mais pas encore fini. C'est plus un choix marketing de montrer ça en premier, car c'est le plus marquant et le plus évident. Comment veux-tu mesurer l'accroissement de productivité sur un nouveau langage ? (que tu dois apprendre donc...)
Il y a des plans et des idées pour essayer de valider statiquement les contracts. La premier chose implémenté dans ce sens est la détection des appels sur NULL.
Pour la facilité d'apprentissage, il y a la syntaxe dont tu fais le tour rapidement et la future lib censé être simple.
J'avais lu un article d'un scientifique bien après la sortie de icc, qui le descendait en flamme.
Il faut dire aussi que gcc a fait des progres. Par exemple, lors des benchs pour Lisaac, on s'est rendu compte que gcc 4.2.1 produit du code environ 30% plus rapide que gcc 2.95 (pour le mpeg2).
Vous comparez les perfs avec gcc, très bien, mais celui-ci n'est pas réputé pour produire du code ultra-performant, pourquoi ne pas plutôt comparer avec le compilo Intel ?
Simplement parce que ce n'est pas vrai. Par default, icc fait des optims uniquement mis en oeuvre par l'option --fast-math sous gcc.
En gros, icc triche et peut donc produire du code faux.
Je rajouterais juste que la commande de compilation de gcc est ecrite en dur dans le fichier path.li. Si on veut ajouter on enlever une bibliotheque, on doit regenerer le generateur de code (lisaac). C'est bof bof.
C'est vrai que j'avais pris l'habitude d'écrire la phase de compilation de gcc à la main, en compilant directement le fichier généré.
Peut-on utiliser un debogueur pas-a-pas sur le code source (le .li) ?
pas encore.
Est-ce-que cette fonctionnalité est prévue dans le futur ?
oui.
A propos du code généré, c'est bourré de variables globales. Tot ou tard il va y avoir des collisions.
Vu qu'il n'y a pas encore de notion de lib, cela ne peut pas arriver.
Je sais que ca fait un peu "je chipote" mais ce sont des problemes qui finiront par ressurgir, surtout si, comme je vous le souhaite, votre projet prend de l'ampleur.
"-funroll-loop" est inclus dans -O3 souvent -funroll-all-loops fait encore mieux. Sinon, je pense que Ontologia pensait faciliter la vie du compilo avec les variables en question.
Par contre il reste un point ou la version en Lisaac est loin derrière la version en C, c'est le temps de compilation...
Forcément en C, c'est toi qui a fait les optims pas le compilo :)
Il y a l'idée de favoriser le libre, en le forçant. On considère Lisaac comme une "killer feature" du libre. C'est vrai aussi, que l'on aurait pu faire une double licence GPLv2/GPLv3 mais bon, on fait simple pour commencer.
Il y a l'idée de refaire le coup de Trolltech ou de MySQL Labs. T'en qu'à avoir de bonnes idées, c'est encore mieux de pouvoir en vivre. Si une personne ne veut pas faire de libre, elle paye.
Est-ce que le modèle de Trolltech est le bon ? Ou celui de Mozilla ? Ou encore celui de Perl, ou encore de PHP ?
Bref, on est pas encore rentré dans ce genre de détails. C'est possible que cela puisse évolué.
1) Je pense que cela n'est qu'une question d'habitude.
2) y'a pas encore de concurrence propre en Lisaac, c'est prévu pour la suite. pthread marche mais c'est pas top.
3) C'est très facile de réutiliser du C. Par contre, il n'y a pas encore de notion de lib partagé.
Je dirais que ton premier cas est vrai, si très peu de client veulent bien mettre beaucoup d'argent. (par exemple le développement de puce, ou des soft pour fondeur, qui doivent être une dizaine dans le monde)
Est-ce pour se permettre un business model à la trolltech (vente de licence pour utilisation de la lib en non GPL) ?
C'est une idée.
Mais pour que cela marche, il faut que les contributeurs à la lib donne leur copyright pour vendre le licence. C'est pas gagné du tout... Or lisaac a besoin de ces contributeurs. Mais lisaac a aussi besoin de moyen pour exister... bref, cela se mord la queue.
[^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 2.
J'avais eu une conf d'un vague présentation du système par un ingénieur renaut qui se faisait brider en live sur ce qu'il pouvait dire.
Mais en gros, j'en avais déduit qu'il devait avoir une dizaine de ppc. Donc 750ko me parait petit :)
"La première sécurité est la liberté"
[^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 1.
Fondamentalement qu'est-ce qui gène ? Le fait que d'habitude, on ne sais pas quand toute la mémoire sera pleine, ce qui empèche de bien tout utiliser ?
"La première sécurité est la liberté"
[^] # Re: sonntag
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 0.
Bah si. Quand tu veux un truc simple, c'est plus lent que le "vieux truc"', à cause de fonctionnalité dont tu n'as pas besoin.
"La première sécurité est la liberté"
[^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 1.
Tu annonce 30 et 170KB, cela ne fait pas beaucoup sauf que les µP 16 bits on difficilement plus de 64KB de mémoire.
pour le bytcode, certe pour mettre sur la pile, tu utilies un mot d'un octet, et minimum 2 octets pour du x86, mais si tu fais une addition entre 2 nombres ailleurs dans la pile, sur x86, cela prendra toujours 2 octets mais combien en byte code java pour manipuler la pile et mettre les valeurs au bon endroit ?
Concernant la mise à jour de code, tu peux tout à fait patcher du binaire. Il n'y a pas vraiment de différence. La difficulté sera toujours la même : comment gérer les données des classes modifiés.
"La première sécurité est la liberté"
[^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: UFRaw et GimpUfraw \o/
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Linux et la photographie : état des lieux. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 1.
Il y a beaucoup de blabla autour de java pour l'embarqué mais très peu d'application réelle. Rien que la RAM nécessaire en plus est un frein.
Sinon, je ne voix pas pourquoi le ByteCode serait plus compact, et de plus, jene voix pas l'interet surtout quand tu as une énorme JVM derrière.
"La première sécurité est la liberté"
[^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 4.
euh... HEIN. Il est fou. On se fait chier à produire du code rapide pour avoir la plateforme moins chère possible et il veut mettre une VM ?!
Du bytecode pour l'embarqué, c'est la meilleur de l'année. Surtout pour des mises à jour, c'est encore pire. (ps:je ne vois pas bien le rapport)
Ca s'est bien amélioré mais ca ne l'a pas empéché d'avoir percé.
Java misait sur une autre approche que Lisaac : sa lib pour gagner du temps.
Lisaac vise autre chose. Plus tangible en plus.
"La première sécurité est la liberté"
[^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 1.
On troll contre 2 langages et tu te sens tellement personnelement visé qu'il faut que tu attaques ?!
"vous avez rien compris avec vos technos de merde, voilà Lisaac, et encore, c'est qu'un début, vous allez voir !",
D'un point de vue purement langage (et non library), Effel ou OCaml sont bien supérieur à java ou c#.
La modularité facilite le déploiement, la maintenance, le partage de code, la souplesse de configuration et de personnalisation, etc.
Sauf que tu mélanges tout. Lisaac est purement objet (dans l'os même le pixel est un objet, et cela ne rame pas !). Tu as donc toutes la réutilisabilité du code, la personnalisation, et la configuration que tu veux. Pour l'instant, il n'y a pas encore de partage de _binaire_ possible. Mais, c'est juste la 1er version...
les algos d'optimisation spécifiques à Lisaac ne sont pertinents que dans les cas ou on fait l'impasse sur ces atouts de la modularité
J'aurais tendance à dire "t'es con ou tu le fais expres". Qu'est-ce qui empèche de faire une optimisation global d'une lib ? Une lib cela peut être aussi énorme ! Un compilo C ne fait des optims que fichiers C par fichier C, il ne va pas plus loin. Lisaac permet ici d'aller plus loin.
où l'on se contente de faire de l'héritage "pour faire joli" au sein d'un même module.
euh... comment dire .... On te dit que Lisaac gère meme l'héritage alimentaire... l'héritage d'implémentation quoi, pas de concept/type. Justement pour faire plus propre que d'habitude... A part ça on troll...
"La première sécurité est la liberté"
[^] # Re: Packaging pour distributions ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 3.
Pas grand chose... surtout depuis que l'on a dis que tout devait se faire en anglais :)
"La première sécurité est la liberté"
[^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 3.
Sinon, ne le prennez pas mal, mais j'ai l'impression que vous vous focalisez un peu trop sur les performances par rapport au C. Ce n'est pas un mal en soit, mais il y a d'autres aspects a prendre en compte, comme la maintenance ou la facilité d'apprentissage.
C'est évidement pris en compte mais pas encore fini. C'est plus un choix marketing de montrer ça en premier, car c'est le plus marquant et le plus évident. Comment veux-tu mesurer l'accroissement de productivité sur un nouveau langage ? (que tu dois apprendre donc...)
Il y a des plans et des idées pour essayer de valider statiquement les contracts. La premier chose implémenté dans ce sens est la détection des appels sur NULL.
Pour la facilité d'apprentissage, il y a la syntaxe dont tu fais le tour rapidement et la future lib censé être simple.
Bref, c'est juste la 1er version majeur...
"La première sécurité est la liberté"
[^] # Re: Benchmark
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 3.
J'avais lu un article d'un scientifique bien après la sortie de icc, qui le descendait en flamme.
Il faut dire aussi que gcc a fait des progres. Par exemple, lors des benchs pour Lisaac, on s'est rendu compte que gcc 4.2.1 produit du code environ 30% plus rapide que gcc 2.95 (pour le mpeg2).
"La première sécurité est la liberté"
[^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 2.
Simplement parce que ce n'est pas vrai. Par default, icc fait des optims uniquement mis en oeuvre par l'option --fast-math sous gcc.
En gros, icc triche et peut donc produire du code faux.
"La première sécurité est la liberté"
[^] # Re: sonntag
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 2.
C'est vrai que j'avais pris l'habitude d'écrire la phase de compilation de gcc à la main, en compilant directement le fichier généré.
Peut-on utiliser un debogueur pas-a-pas sur le code source (le .li) ?
pas encore.
Est-ce-que cette fonctionnalité est prévue dans le futur ?
oui.
A propos du code généré, c'est bourré de variables globales. Tot ou tard il va y avoir des collisions.
Vu qu'il n'y a pas encore de notion de lib, cela ne peut pas arriver.
Je sais que ca fait un peu "je chipote" mais ce sont des problemes qui finiront par ressurgir, surtout si, comme je vous le souhaite, votre projet prend de l'ampleur.
On est tout ouï. :)
"La première sécurité est la liberté"
[^] # Re: sonntag
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 4.
Par contre il reste un point ou la version en Lisaac est loin derrière la version en C, c'est le temps de compilation...
Forcément en C, c'est toi qui a fait les optims pas le compilo :)
"La première sécurité est la liberté"
[^] # Re: Vaccination
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 2.
Il y a l'idée de favoriser le libre, en le forçant. On considère Lisaac comme une "killer feature" du libre. C'est vrai aussi, que l'on aurait pu faire une double licence GPLv2/GPLv3 mais bon, on fait simple pour commencer.
Il y a l'idée de refaire le coup de Trolltech ou de MySQL Labs. T'en qu'à avoir de bonnes idées, c'est encore mieux de pouvoir en vivre. Si une personne ne veut pas faire de libre, elle paye.
Est-ce que le modèle de Trolltech est le bon ? Ou celui de Mozilla ? Ou encore celui de Perl, ou encore de PHP ?
Bref, on est pas encore rentré dans ce genre de détails. C'est possible que cela puisse évolué.
"La première sécurité est la liberté"
[^] # Re: license et divers points techniques
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 2.
2) y'a pas encore de concurrence propre en Lisaac, c'est prévu pour la suite. pthread marche mais c'est pas top.
3) C'est très facile de réutiliser du C. Par contre, il n'y a pas encore de notion de lib partagé.
"La première sécurité est la liberté"
[^] # Re: sonntag
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 1.
Tout est objet même les clause logique du if, même les bloc de code des 2 branches du if...
Une fois que tu as compris ça, tout devient plus claire :)
"La première sécurité est la liberté"
[^] # Re: Pertinence de cette dépeche ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: Pertinence de cette dépeche ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 1.
Tu mélanges la licence du compilo et la licence de la library qui va avec.
"La première sécurité est la liberté"
[^] # Re: Vaccination
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 2.
C'est une idée.
Mais pour que cela marche, il faut que les contributeurs à la lib donne leur copyright pour vendre le licence. C'est pas gagné du tout... Or lisaac a besoin de ces contributeurs. Mais lisaac a aussi besoin de moyen pour exister... bref, cela se mord la queue.
"La première sécurité est la liberté"