Bah je suis déçu, t'as compris que la moitié de mon deuxième degré. Je répond court parce que je commence a saturer (et puis, dans la vie, on nourrit les trolls en discutant ou on les tue en codant, hein..)
> ça prouve juste que ça ne prouve rien ;-)
+1
> Je critique le bench qui utilise un programme sans interet pour monter on ne sais pas trop quoi...
si tu vois pas l'intérêt d'un micro-bench, alors n'en parle même pas. Critiquer quelque-chose est utile uniquement si tu penses que ça peut l'améliorer. Penses-tu sérieusement t'impliquer dans le développement d'ooc?
> Bah non ce n'est pas ce que tu as répété
bizarrement, on dirait qu'on peut répéter 2 choses a la fois, dont "Ces résultats, bien que peu fiables [,,,]", "J'ai déjà moi-même dit et répété qu'un micro-benchmark ne voulait pas dire grand-chose", "Comme tous les benchmarks, a prendre avec des pincettes.", "Si tu as les sources de benchmarks plus réalistes écrits"
Donc non seulement tu prêches a un converti mais en plus tu pars du principe que c'est un mauvais programmeur. Je te suggère d'imaginer la situation suivante: un programme divisé en 10 sous-systèmes, qui exécutent tous 100 tâches en "parallèle" pour chacun de leurs 100 clients (ou requêtes). Chacune des tâches a besoin d'allouer environ 1000 objets, de types et de taille différentes (aucun intérêt de pooler, donc). Qu'obtient-on? entre autres choses (calcul, entrées/sorties, etc.), 100 millions d'allocation d'objets en quelques secondes, à savoir le micro-benchmark ci-dessus. Sauf que ce programme que je te demande d'imaginer (mais qui ressemble bien a plusieurs programmes réels et en production) n'est pas si facilement optimisable qu'un micro-benchmark, précisément parce que les allocations sont de tous types et disséminées partout dans le code. D'où l'intérêt de tester la vitesse pure d'allocation. Avec tout le côté hasardeux, imprécis, et générateur de troll que ça a.
> Moi quand je vois ce genre de bench, je trouve que ça pue la mauvaise fois et que le dev à chercher un moyen de montrer à tout pris que son langage est meilleur, et pour ça il à chercher le seul code ou c'est le cas. Quel que soit ton objectif, se genre de bench ne peut que te désservir. Soit tu ne fais pas de bench, soit tu en fais un serrieux, mais avec un comme celui là tu ne fais que décrédibiliser ton langage.
Bah. Ce que tu dis serait valable si j'en avais fait tout un fromage en clamant a tout va qu'ooc est plus rapide que C++ de manière générale et si j'en avais fait une raison d'adopter ooc, dans mon argumentation. Or ce n'est pas le cas.
Pour ce qui est d'un benchmark sérieux, je n'ai pas le temps dans la semaine qui vient, mais par simple curiosité (non, je ne suis pas si obsédé que ça par les performances) j'essayerais d'en trouver un potable (qui teste plusieurs aspects). Je pensais porter alioth shootout, a un moment. Mais bon "premature optimization is the root of all evil" donc je vais plutot me concentrer sur une langage plus propre et syntaxiquement bien plus sympathique que le C++ (enfin c'est mon avis..)
> Tu semble très content que OCC gérèe «plus légerement les objets» que C++, mais c'est à quel prix ?
Je ne comprend pas la question. Je ne vois pas de prix a être plus léger, sinon éventuellement en facilité d'utilisation, ce qui n'est clairement pas le cas, de plus ta remarque qui suit présent l'argument exactement inverse.
> est-ce que C++ en acceptant d'utiliser un pool n'est pas au final meilleur ?
Ben c't'a dire que non puisque la performance n'était pas du tout ma raison principael de faire/d'utiliser ooc. Ce qui me chagrinait en principal dans le C++ était la syntaxe, et l'absence d'une ABI standard.
> j'ai du mal a voir le rapport avec Firefox
Ton argumentation : "gérer la mémoire correctement sans GC est trivial"
Ma réponse : "va dire ça aux devs de grosses applications."
> c'est pas parce qu'il y a des coins bouseux dans le C++ que tu es obligé de les explorer...
Pour info, C++0x est le futur du C++. Si son futur est bouseux (d'après toi) c'est pas vraiment ma faute.
> j'ai vu des programmeurs obligés de se mettre au jiu jitsu pour faire des pools dans le langage X
Je comprend que tu as cette discussions uniquement par fierté, par fanatisme du C++&co, et pour afficher ton grand savoir, mais tu pourrais faire l'effort de lire ce que je raconte sur l'avenir d'ooc. Résumons, à l'avenir: 3 options intégrées dans le langage: GC, pool, et malloc/free manuel. Et pour les allocations par blocs, une syntaxe comme "Object o = 300 new Object()" devrait faire l'affaire.
> mais le deuxième est tout à fait réaliste.
Absolument, c'est un des défauts connus des GC conservatifs. D'où le fait que je considère l'éventualité, comme ooc est fortement typé, d'en réécrire un précis pour les prochaines versions.
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Amos Wenger . En réponse à la dépêche Le language de programmation ooc sorti en version 0.2. Évalué à 2.
> ça prouve juste que ça ne prouve rien ;-)
+1
> Je critique le bench qui utilise un programme sans interet pour monter on ne sais pas trop quoi...
si tu vois pas l'intérêt d'un micro-bench, alors n'en parle même pas. Critiquer quelque-chose est utile uniquement si tu penses que ça peut l'améliorer. Penses-tu sérieusement t'impliquer dans le développement d'ooc?
> Bah non ce n'est pas ce que tu as répété
bizarrement, on dirait qu'on peut répéter 2 choses a la fois, dont "Ces résultats, bien que peu fiables [,,,]", "J'ai déjà moi-même dit et répété qu'un micro-benchmark ne voulait pas dire grand-chose", "Comme tous les benchmarks, a prendre avec des pincettes.", "Si tu as les sources de benchmarks plus réalistes écrits"
Donc non seulement tu prêches a un converti mais en plus tu pars du principe que c'est un mauvais programmeur. Je te suggère d'imaginer la situation suivante: un programme divisé en 10 sous-systèmes, qui exécutent tous 100 tâches en "parallèle" pour chacun de leurs 100 clients (ou requêtes). Chacune des tâches a besoin d'allouer environ 1000 objets, de types et de taille différentes (aucun intérêt de pooler, donc). Qu'obtient-on? entre autres choses (calcul, entrées/sorties, etc.), 100 millions d'allocation d'objets en quelques secondes, à savoir le micro-benchmark ci-dessus. Sauf que ce programme que je te demande d'imaginer (mais qui ressemble bien a plusieurs programmes réels et en production) n'est pas si facilement optimisable qu'un micro-benchmark, précisément parce que les allocations sont de tous types et disséminées partout dans le code. D'où l'intérêt de tester la vitesse pure d'allocation. Avec tout le côté hasardeux, imprécis, et générateur de troll que ça a.
> Moi quand je vois ce genre de bench, je trouve que ça pue la mauvaise fois et que le dev à chercher un moyen de montrer à tout pris que son langage est meilleur, et pour ça il à chercher le seul code ou c'est le cas. Quel que soit ton objectif, se genre de bench ne peut que te désservir. Soit tu ne fais pas de bench, soit tu en fais un serrieux, mais avec un comme celui là tu ne fais que décrédibiliser ton langage.
Bah. Ce que tu dis serait valable si j'en avais fait tout un fromage en clamant a tout va qu'ooc est plus rapide que C++ de manière générale et si j'en avais fait une raison d'adopter ooc, dans mon argumentation. Or ce n'est pas le cas.
Pour ce qui est d'un benchmark sérieux, je n'ai pas le temps dans la semaine qui vient, mais par simple curiosité (non, je ne suis pas si obsédé que ça par les performances) j'essayerais d'en trouver un potable (qui teste plusieurs aspects). Je pensais porter alioth shootout, a un moment. Mais bon "premature optimization is the root of all evil" donc je vais plutot me concentrer sur une langage plus propre et syntaxiquement bien plus sympathique que le C++ (enfin c'est mon avis..)
> Tu semble très content que OCC gérèe «plus légerement les objets» que C++, mais c'est à quel prix ?
Je ne comprend pas la question. Je ne vois pas de prix a être plus léger, sinon éventuellement en facilité d'utilisation, ce qui n'est clairement pas le cas, de plus ta remarque qui suit présent l'argument exactement inverse.
> est-ce que C++ en acceptant d'utiliser un pool n'est pas au final meilleur ?
Ben c't'a dire que non puisque la performance n'était pas du tout ma raison principael de faire/d'utiliser ooc. Ce qui me chagrinait en principal dans le C++ était la syntaxe, et l'absence d'une ABI standard.
> j'ai du mal a voir le rapport avec Firefox
Ton argumentation : "gérer la mémoire correctement sans GC est trivial"
Ma réponse : "va dire ça aux devs de grosses applications."
> c'est pas parce qu'il y a des coins bouseux dans le C++ que tu es obligé de les explorer...
Pour info, C++0x est le futur du C++. Si son futur est bouseux (d'après toi) c'est pas vraiment ma faute.
> j'ai vu des programmeurs obligés de se mettre au jiu jitsu pour faire des pools dans le langage X
Je comprend que tu as cette discussions uniquement par fierté, par fanatisme du C++&co, et pour afficher ton grand savoir, mais tu pourrais faire l'effort de lire ce que je raconte sur l'avenir d'ooc. Résumons, à l'avenir: 3 options intégrées dans le langage: GC, pool, et malloc/free manuel. Et pour les allocations par blocs, une syntaxe comme "Object o = 300 new Object()" devrait faire l'affaire.
> mais le deuxième est tout à fait réaliste.
Absolument, c'est un des défauts connus des GC conservatifs. D'où le fait que je considère l'éventualité, comme ooc est fortement typé, d'en réécrire un précis pour les prochaines versions.