Je vais résumé mon point de vue en essayant d'être plus clair car j'ai l'impréssion que ce n'était pas le cas : Un bench qui n'est pas fait correctement, même s'il peut être marrant quand on le fait dans son coin, fait du mal au langage de manière général quand il est public comme celui que tu propose ici :
- Tu peut mettre tous les avertissement sur le fait que ce que tu vas dire est une grosse connerie, il y aura toujours des personnes pour reprendre tes chiffres et les utiliser comme une parole d'évangile. Les gens aiment les chiffres même lorsqu'ils sont faux, il suffit de regarder les débats sur les perfs de java ou autres langage de haut-niveau ;
- Pour quelqu'un qui regarde le bench d'un peu plus près, tu donne l'impression d'avoir chercher un cas à tout pris où tes perfs sont meilleur que celle du langage auquel tu te compare (même si ce n'est pas forcément le cas) donc tu perd toute crédibilité. Donc même si ton langage est bon, tu pousse les gens que cela pourrait intéresser à passer leur chemin.
Ce que je critique dans mes message c'est principalement le fait de publier un bench tels que celui que tu donne. Les chiffres que tu donne ne veulent strictement rien dire à l'exception d'un cas très particulier qui n'apparait pas jamais dans la vraie vie. Le programme auquel tu l'oppose est trivialement mal programmé pour quelqu'un qui connait le C++, alors que l'on peut supposer que celui en OCC est bien codé puisque c'est ton langage, on peut donc en déduire que tu est de mauvaise foie.
Bref, même si cela part d'une bonne intention, je pense que ton bench fait plus de mal qu'autre chose, et c'est général pour les mauvais benchs. Après, c'est peut-être moi qui suit tordu et qui voit le mal partout, mais au niveau bench j'ai vu le meilleur comme le pire, et j'ai pris l'habitude de me méfier de chiffre donnée sur la base des micro-bench.
Mais de ce que j'ai pus voir les gens gobent ces chiffre aveuglément et globalement c'est plus facile de ce battre contre les mauvais bench que contre les idées qu'ils ont répendues.
[...]exemple avec plein de systeme qui créent des objets dans tous les sens[..]
Ton exemple illustre tout à fait ce que je critique, même si la création/libération des objets est un facteur important : dans le cas que tu illustres, il y a beaucoup de chose qui ce passe en plus de ces opérations. Notament, et c'est souvnt très important les objets sont rarement libérés dans le même ordre qu'ils sont créés, certains ont une durée de vie bien plus longue que les autres, beaucoup de paramètres entrent en jeu. Au final on est très loin de la situtation idéale du micro-bench que tu présente.
Résultat : dans ce cas réaliste les perfs du GC doivent chuter dramatiquement et au final les perfs sont surement au mieux similaires à celle du C++.
Ton argumentation : "gérer la mémoire correctement sans GC est trivial"
Ma réponse : "va dire ça aux devs de grosses applications."
Ne me fais pas dire ce que je n'ai pas dit. Nulle part je ne dit que gérer la mémoire sans GC est trivial. Ce que je dis c'est que,dans un cas comme celui de ton micro bench, l'utilisation d'un pool est très simple : un grand nombre d'objet tous de même taille à allouer et libérer dans une portion réduite du code.
De manière générale, l'utilisation de pool reste relativement simple tant que tu restes sur l'allocation d'un grand nombre d'objets identiques et dans ces cas là, c'est à ma connaissance toujours plus éfficace d'utiliser un pool qu'un GC.
Si tes objets sont de tailles variable et contiennent des références les un aux autres, je suis d'accord qu'un GC deviens intéressant et qu'un pool n'est plus adapté.
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.
Je suis loin d'être un fan du C++ contrairement à ce que tu dis, j'ai parlé du C++ car ton bench comparait OCC à C++ uniquement. Donc si tu veut délirer sur ma fierté et mon grand savoir libre à toi, mais fais comme pour le bench qui ne veulent rien dire, s'il te plait, ne les publies pas.
Pour ton information et pour t'éviter de me relire, je suis pour le choix de la solution adaptée à chaque problèmes, et donc dans le cadre de ton micro bench pour la version en C++ c'est un pool et pas une gestion basique qu'il faut utiliser.
L'avenir de OOC et le fait de pouvoir utiliser plusieurs modèles d'allocation mémoire c'est au dernier message que tu as commencé à en parler, je t'ai même répodu que ce serait bien de le faire, donc depuis que tu en parle, je pense l'avoir lut et en avoir tenu compte...
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par beagf . En réponse à la dépêche Le language de programmation ooc sorti en version 0.2. Évalué à 2.
- Tu peut mettre tous les avertissement sur le fait que ce que tu vas dire est une grosse connerie, il y aura toujours des personnes pour reprendre tes chiffres et les utiliser comme une parole d'évangile. Les gens aiment les chiffres même lorsqu'ils sont faux, il suffit de regarder les débats sur les perfs de java ou autres langage de haut-niveau ;
- Pour quelqu'un qui regarde le bench d'un peu plus près, tu donne l'impression d'avoir chercher un cas à tout pris où tes perfs sont meilleur que celle du langage auquel tu te compare (même si ce n'est pas forcément le cas) donc tu perd toute crédibilité. Donc même si ton langage est bon, tu pousse les gens que cela pourrait intéresser à passer leur chemin.
Ce que je critique dans mes message c'est principalement le fait de publier un bench tels que celui que tu donne. Les chiffres que tu donne ne veulent strictement rien dire à l'exception d'un cas très particulier qui n'apparait pas jamais dans la vraie vie. Le programme auquel tu l'oppose est trivialement mal programmé pour quelqu'un qui connait le C++, alors que l'on peut supposer que celui en OCC est bien codé puisque c'est ton langage, on peut donc en déduire que tu est de mauvaise foie.
Bref, même si cela part d'une bonne intention, je pense que ton bench fait plus de mal qu'autre chose, et c'est général pour les mauvais benchs. Après, c'est peut-être moi qui suit tordu et qui voit le mal partout, mais au niveau bench j'ai vu le meilleur comme le pire, et j'ai pris l'habitude de me méfier de chiffre donnée sur la base des micro-bench.
Mais de ce que j'ai pus voir les gens gobent ces chiffre aveuglément et globalement c'est plus facile de ce battre contre les mauvais bench que contre les idées qu'ils ont répendues.
[...]exemple avec plein de systeme qui créent des objets dans tous les sens[..]
Ton exemple illustre tout à fait ce que je critique, même si la création/libération des objets est un facteur important : dans le cas que tu illustres, il y a beaucoup de chose qui ce passe en plus de ces opérations. Notament, et c'est souvnt très important les objets sont rarement libérés dans le même ordre qu'ils sont créés, certains ont une durée de vie bien plus longue que les autres, beaucoup de paramètres entrent en jeu. Au final on est très loin de la situtation idéale du micro-bench que tu présente.
Résultat : dans ce cas réaliste les perfs du GC doivent chuter dramatiquement et au final les perfs sont surement au mieux similaires à celle du C++.
Ton argumentation : "gérer la mémoire correctement sans GC est trivial"
Ma réponse : "va dire ça aux devs de grosses applications."
Ne me fais pas dire ce que je n'ai pas dit. Nulle part je ne dit que gérer la mémoire sans GC est trivial. Ce que je dis c'est que,dans un cas comme celui de ton micro bench, l'utilisation d'un pool est très simple : un grand nombre d'objet tous de même taille à allouer et libérer dans une portion réduite du code.
De manière générale, l'utilisation de pool reste relativement simple tant que tu restes sur l'allocation d'un grand nombre d'objets identiques et dans ces cas là, c'est à ma connaissance toujours plus éfficace d'utiliser un pool qu'un GC.
Si tes objets sont de tailles variable et contiennent des références les un aux autres, je suis d'accord qu'un GC deviens intéressant et qu'un pool n'est plus adapté.
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.
Je suis loin d'être un fan du C++ contrairement à ce que tu dis, j'ai parlé du C++ car ton bench comparait OCC à C++ uniquement. Donc si tu veut délirer sur ma fierté et mon grand savoir libre à toi, mais fais comme pour le bench qui ne veulent rien dire, s'il te plait, ne les publies pas.
Pour ton information et pour t'éviter de me relire, je suis pour le choix de la solution adaptée à chaque problèmes, et donc dans le cadre de ton micro bench pour la version en C++ c'est un pool et pas une gestion basique qu'il faut utiliser.
L'avenir de OOC et le fait de pouvoir utiliser plusieurs modèles d'allocation mémoire c'est au dernier message que tu as commencé à en parler, je t'ai même répodu que ce serait bien de le faire, donc depuis que tu en parle, je pense l'avoir lut et en avoir tenu compte...