> Ton benchmark ne prouve qu'une chose
Ah bon ca prouve qqch, les micro-benchs? Je croyais que ça voulait rien dire.
Pour entrer dans le jeu, ça prouve juste que ça ne prouve rien ;-)
> Il n'y a aucun interet au programme que tu montre
Ma foi je vois pas pourquoi tu prends la peine de le critiquer alors.
Je critique le bench qui utilise un programme sans interet pour monter on ne sais pas trop quoi...
> ce benchmark ne veut absolument rien dire
C'est pas ce que j'ai répété dans presque tous mes posts en haut?
Bah non ce n'est pas ce que tu as répété come tu le dis si bien juste après :
La seule chose que j'ai suggérée, c'est que pour une tâche très précise (et codée naivement) mais finalement pas si irréaliste, les résultats du microbench semblaient montrer qu'ooc implémentait les classes de manière plus légère, c'est tout. Les tests suggérés par bbfok avec l'allocateur TCMalloc montre qu'à conditions égales, le C++ peut outperformer ooc si on prive ce dernier de son GC activé par défaut. Il me semble pas avoir posté "HOLY SCHMOLY, OOC 0.2 BLOWS C++ AWAY"
Une tâche très précise qui ne se produit jamais en dans un vrai code et en plus mal coder de manière à déformer les résultats du bench ? Ça c'est du bench intéressant...
Tout ce que tu réussit à faire avec ton bench c'est dire «dans un cas que vous ne rencontrerez jamais dans la réalitée OOC fait mieux que C++ (et encore /une/ implémentation de C++), mais pour des cas réaliste je vous laisse deviner.»
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.
ou quand tu veux juste avoir une idée vague des performances d'une implémentation d'un langage sous certaines conditions.
Tout d'abord ce que tu fais n'est pas un vrai bench dans le sens ou tu biaise un des langages testés en l'utilisant mal. Si je fais un bench entre du C du CAML je peut déjà te dire que CAML sera dix fois plus lent et pourtant certains on montrer qu'il avait des perfs honorables.
Ensuite où est l'interet d'un bench qui mesure des performances même vagues dans des conditions telles qu'elles ne seront jamais rencontrer dans aucun programme ?
> en réalité tu ne fais pas un ++ sur variable
c'est marrant parce que j'ai écrit plein de programmes dans ma vie et j'ai souvent utilisé ++. Plus sérieusement, tu crois pas que si je faisais rien ave l'objet, je courrais le risque que g++/gcc se sente fou et me vire carrément ma boucle? Mieux vaux etre doublement sûr.
Je pense que tu le fais exprès mais au cas ou... Je ne critique pas le fait que tu fasse un ++, ce que je critique c'est que tu ne fasse que ça. Tu as souvent écrit des programme qui créait un million d'objet pour juste faire un ++ sur une variable et ensuite libéré l'objet ?
Tu semble très content que OCC gérèe «plus légerement les objets» que C++, mais c'est à quel prix ? C'est ce point qui est important. Ce qu'il faut te poser comme question c'est, qu'ai je sacrifier pour ça et est-ce que ça vaut le cout ?
C'est la même chose que l'argument classique en faveur des GCs : On perd générallement un petit peu en perf mais on y gagne une facilitée d'utilisation.
Tu gagne par rapport à C++ lors de la création de grande quantitée d'objet sans utilisation de pool, mais dans des condition réelle ou chaque objet réalise un vrai traitement tu ne gagne qu'un pouième de perfs, est-ce que c'est valable ? est-ce que C++ en acceptant d'utiliser un pool n'est pas au final meilleur ?
(vrai question puisque je ne sais pas comment marche OOC)
> Dans le cadre d'une vrai application ce genre d'«optimisation» n'est pas couteux en dévelopement et en maintenance.
il a raison! tout le monde sait par exemple que Firefox gère parfaitement sa mémoire, et n'a jamais eu historiquement de grosses fuites mémoires et qu'il n'ont pas du tout passé des mois a essayer d'optimiser leurs routines d'allocations mémoire (comme ne le confirme pas le lien posté plus haut par son-nom-m'échappe)
Là j'ai du mal à voir le rapport avec Firefox. Si j'écrit une appli en OOC qui à plein de fuite mémoire ça veut dire que OOC est une merde ?
Le gros problème de Firefox c'est que la gestion mémoire à été conçue progressivement en rajoutant des couches petit à petit. Le lien que tu indiques montre que la mémoire se fragmente et donc qu'elle ne peut être récupéré par le système. Ce problème n'est pas lié au C++ ou à des pool ou n'importe quoi d'autre, un GC aurra éxactement le même.
Si tu allous un million de petits objets et que tu en libère un sur deux, quel que soit le système que tu utilises tu ne pourra pas libéré la mémoire. A moin d'utiliser un GC compacteur mais là ça pose d'énorme problème puisque tout les pointeur doivent être indirects.
Bien au contraire, un système de pool peut même améliorer la situation car il t'assure que les objets de même types sont regroupés au même endroit, donc il facilite la gestion.
Bon eh bien voilà une suggestion intéressante. A la réflexion, je ne vois pas de bonne raison de "forcer la main" des programmeurs ooc et de leur imposer le gc. J'entrevois la possibilité de pouvoir spécifier dans le code quel type d'allocation on préfère a l'instanciation: GC, pool, ou manuel. Tout ça intégré dans le langage, comme Antoine le suggère.
Ça c'est déjà mieux. Intégrer dans le langage ce que l'on fait de manière plus crade en C++ serait pas mal à condition que ce soit fait proprement ;-)
> il faut être capable de choisir le langage adapté à la tache et à l'environement.
eeeeeeeh copieur c'est moi qui l'ai dit en premier ça. (et pas qu'une fois en plus). Si y'a triche, moi je joue plus hein.
D'un autre côté, ça fait des années que je le dis, et je suis sûr que d'autres l'on dis avant nous. Heureusement qu'il n'y a pas encore de brevets sur les opinions....
> C'est un joli mythe mais dans la réalité c'est loin d'être toujours le cas.
A cette différence près c'est que quand tu codes dans un langage bien établi comme le C++ tu regarde tristement la réalité en face, tu soupires, et tu remets a coder de manière fastidieuse parce que c'est trop tard pour changer (oui je connais le standard C++0x, et j'avoue que ça m'impressione: ils ont réussi à rendre le langage encore plus complexe et error-prone qu'avant. Je pensais pas que c'était possible.)
Pour le C++, j'ai un ensemble classes et de templates que je réutilise à chaque fois que j'en ai besoin et qui me font ce genre de merde toutes seules. Ensuite, c'est pas parce qu'il y a des coins bouseux dans le C++ que tu es obligé de les explorer...
Et pour retourner le compliment, j'ai vu des programmeur (paix à leurs âmes) qui, obligé de programmer dans un langage qui pensait savoir mieux qu'eux comment gérer la mémoire était obliger de passer par de grand tableaux d'objets pour émuler les pool si simple à coder en C ou en C++. Bien sûr c'est pas des cas courrant, et c'est loin d'être systématiquement valable, mais ça arrive à mon avis plus souvent que créer un million do'bjets juste pour faire un ++....
> strings immutables (oh oui), et cacher des choses dans les langages de haut niveau.
J'ai toujours été dubitatif quant a l'intérêt de l'immutabilité des Strings en Java (puisque c'est le langage avec lequel j'ai travaillé le plus), à part pour ceux qui ne savent pas ou ils passent leur Strings (auquel cas il faudrait penser sérieusement a arrêter la biosson, mon vieux). En résumé, ooc n'impose pas l'immutabilité d'une String.
Je ne lance pas le débat sur l'immutabilité des string mais sur le fait qu'il est dangeureux de cacher des chose, surtout dans les éléments de base d'un langage. Je voulais surtout montrer les effets pervers que peuvent avoir dans certains cas le GC et bien expliquer que ce n'est pas la solution ultime et que la gestion manuelle de la mémoire n'est pas le mal absolu.
Quant a cacher des choses dans les langages de haut niveau ben à ce moment là.. C++ par exemple. Cf. [http://yosefk.com/c++fqa/] mais aussi [http://www.johndeacon.net/Cpp/trapsAndPitfalls.asp]
Pour ooc, rien n'est caché: l'implémentation du langage est simple, et tout ce qu'on a besoin de savoir sur comment c'est fait en dessous est dans le language reference guide (et si ça n'y est pas, c'est que ça manque, prévenez-moi et je complèterais.) L'avantage? Travailler avec un langage qu'on peut facilement maîtriser, se rendre compte qu'on a fait la même chose en C à la main depuis longtemps, et être même capable de faire des contributions valables au langage.
Et le jour ou un programmeur stockera un poiteur vers un objet de manière un peu cryptée ou utilisera une variable entière dont la valeure est la même que l'adresse d'un objet qui traine quelque part, le Bohem GC va se planter et l programmeur aurra une surprise...
J'admet que le premier cas relève d'une connerie de la part du programmeur, mais le deuxième est tout à fait réaliste.
[^] # 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é à 3.
Ah bon ca prouve qqch, les micro-benchs? Je croyais que ça voulait rien dire.
Pour entrer dans le jeu, ça prouve juste que ça ne prouve rien ;-)
> Il n'y a aucun interet au programme que tu montre
Ma foi je vois pas pourquoi tu prends la peine de le critiquer alors.
Je critique le bench qui utilise un programme sans interet pour monter on ne sais pas trop quoi...
> ce benchmark ne veut absolument rien dire
C'est pas ce que j'ai répété dans presque tous mes posts en haut?
Bah non ce n'est pas ce que tu as répété come tu le dis si bien juste après :
La seule chose que j'ai suggérée, c'est que pour une tâche très précise (et codée naivement) mais finalement pas si irréaliste, les résultats du microbench semblaient montrer qu'ooc implémentait les classes de manière plus légère, c'est tout. Les tests suggérés par bbfok avec l'allocateur TCMalloc montre qu'à conditions égales, le C++ peut outperformer ooc si on prive ce dernier de son GC activé par défaut. Il me semble pas avoir posté "HOLY SCHMOLY, OOC 0.2 BLOWS C++ AWAY"
Une tâche très précise qui ne se produit jamais en dans un vrai code et en plus mal coder de manière à déformer les résultats du bench ? Ça c'est du bench intéressant...
Tout ce que tu réussit à faire avec ton bench c'est dire «dans un cas que vous ne rencontrerez jamais dans la réalitée OOC fait mieux que C++ (et encore /une/ implémentation de C++), mais pour des cas réaliste je vous laisse deviner.»
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.
ou quand tu veux juste avoir une idée vague des performances d'une implémentation d'un langage sous certaines conditions.
Tout d'abord ce que tu fais n'est pas un vrai bench dans le sens ou tu biaise un des langages testés en l'utilisant mal. Si je fais un bench entre du C du CAML je peut déjà te dire que CAML sera dix fois plus lent et pourtant certains on montrer qu'il avait des perfs honorables.
Ensuite où est l'interet d'un bench qui mesure des performances même vagues dans des conditions telles qu'elles ne seront jamais rencontrer dans aucun programme ?
> en réalité tu ne fais pas un ++ sur variable
c'est marrant parce que j'ai écrit plein de programmes dans ma vie et j'ai souvent utilisé ++. Plus sérieusement, tu crois pas que si je faisais rien ave l'objet, je courrais le risque que g++/gcc se sente fou et me vire carrément ma boucle? Mieux vaux etre doublement sûr.
Je pense que tu le fais exprès mais au cas ou... Je ne critique pas le fait que tu fasse un ++, ce que je critique c'est que tu ne fasse que ça. Tu as souvent écrit des programme qui créait un million d'objet pour juste faire un ++ sur une variable et ensuite libéré l'objet ?
Tu semble très content que OCC gérèe «plus légerement les objets» que C++, mais c'est à quel prix ? C'est ce point qui est important. Ce qu'il faut te poser comme question c'est, qu'ai je sacrifier pour ça et est-ce que ça vaut le cout ?
C'est la même chose que l'argument classique en faveur des GCs : On perd générallement un petit peu en perf mais on y gagne une facilitée d'utilisation.
Tu gagne par rapport à C++ lors de la création de grande quantitée d'objet sans utilisation de pool, mais dans des condition réelle ou chaque objet réalise un vrai traitement tu ne gagne qu'un pouième de perfs, est-ce que c'est valable ? est-ce que C++ en acceptant d'utiliser un pool n'est pas au final meilleur ?
(vrai question puisque je ne sais pas comment marche OOC)
> Dans le cadre d'une vrai application ce genre d'«optimisation» n'est pas couteux en dévelopement et en maintenance.
il a raison! tout le monde sait par exemple que Firefox gère parfaitement sa mémoire, et n'a jamais eu historiquement de grosses fuites mémoires et qu'il n'ont pas du tout passé des mois a essayer d'optimiser leurs routines d'allocations mémoire (comme ne le confirme pas le lien posté plus haut par son-nom-m'échappe)
Là j'ai du mal à voir le rapport avec Firefox. Si j'écrit une appli en OOC qui à plein de fuite mémoire ça veut dire que OOC est une merde ?
Le gros problème de Firefox c'est que la gestion mémoire à été conçue progressivement en rajoutant des couches petit à petit. Le lien que tu indiques montre que la mémoire se fragmente et donc qu'elle ne peut être récupéré par le système. Ce problème n'est pas lié au C++ ou à des pool ou n'importe quoi d'autre, un GC aurra éxactement le même.
Si tu allous un million de petits objets et que tu en libère un sur deux, quel que soit le système que tu utilises tu ne pourra pas libéré la mémoire. A moin d'utiliser un GC compacteur mais là ça pose d'énorme problème puisque tout les pointeur doivent être indirects.
Bien au contraire, un système de pool peut même améliorer la situation car il t'assure que les objets de même types sont regroupés au même endroit, donc il facilite la gestion.
Bon eh bien voilà une suggestion intéressante. A la réflexion, je ne vois pas de bonne raison de "forcer la main" des programmeurs ooc et de leur imposer le gc. J'entrevois la possibilité de pouvoir spécifier dans le code quel type d'allocation on préfère a l'instanciation: GC, pool, ou manuel. Tout ça intégré dans le langage, comme Antoine le suggère.
Ça c'est déjà mieux. Intégrer dans le langage ce que l'on fait de manière plus crade en C++ serait pas mal à condition que ce soit fait proprement ;-)
> il faut être capable de choisir le langage adapté à la tache et à l'environement.
eeeeeeeh copieur c'est moi qui l'ai dit en premier ça. (et pas qu'une fois en plus). Si y'a triche, moi je joue plus hein.
D'un autre côté, ça fait des années que je le dis, et je suis sûr que d'autres l'on dis avant nous. Heureusement qu'il n'y a pas encore de brevets sur les opinions....
> C'est un joli mythe mais dans la réalité c'est loin d'être toujours le cas.
A cette différence près c'est que quand tu codes dans un langage bien établi comme le C++ tu regarde tristement la réalité en face, tu soupires, et tu remets a coder de manière fastidieuse parce que c'est trop tard pour changer (oui je connais le standard C++0x, et j'avoue que ça m'impressione: ils ont réussi à rendre le langage encore plus complexe et error-prone qu'avant. Je pensais pas que c'était possible.)
Pour le C++, j'ai un ensemble classes et de templates que je réutilise à chaque fois que j'en ai besoin et qui me font ce genre de merde toutes seules. Ensuite, c'est pas parce qu'il y a des coins bouseux dans le C++ que tu es obligé de les explorer...
Et pour retourner le compliment, j'ai vu des programmeur (paix à leurs âmes) qui, obligé de programmer dans un langage qui pensait savoir mieux qu'eux comment gérer la mémoire était obliger de passer par de grand tableaux d'objets pour émuler les pool si simple à coder en C ou en C++. Bien sûr c'est pas des cas courrant, et c'est loin d'être systématiquement valable, mais ça arrive à mon avis plus souvent que créer un million do'bjets juste pour faire un ++....
> strings immutables (oh oui), et cacher des choses dans les langages de haut niveau.
J'ai toujours été dubitatif quant a l'intérêt de l'immutabilité des Strings en Java (puisque c'est le langage avec lequel j'ai travaillé le plus), à part pour ceux qui ne savent pas ou ils passent leur Strings (auquel cas il faudrait penser sérieusement a arrêter la biosson, mon vieux). En résumé, ooc n'impose pas l'immutabilité d'une String.
Je ne lance pas le débat sur l'immutabilité des string mais sur le fait qu'il est dangeureux de cacher des chose, surtout dans les éléments de base d'un langage. Je voulais surtout montrer les effets pervers que peuvent avoir dans certains cas le GC et bien expliquer que ce n'est pas la solution ultime et que la gestion manuelle de la mémoire n'est pas le mal absolu.
Quant a cacher des choses dans les langages de haut niveau ben à ce moment là.. C++ par exemple. Cf. [http://yosefk.com/c++fqa/] mais aussi [http://www.johndeacon.net/Cpp/trapsAndPitfalls.asp]
Pour ooc, rien n'est caché: l'implémentation du langage est simple, et tout ce qu'on a besoin de savoir sur comment c'est fait en dessous est dans le language reference guide (et si ça n'y est pas, c'est que ça manque, prévenez-moi et je complèterais.) L'avantage? Travailler avec un langage qu'on peut facilement maîtriser, se rendre compte qu'on a fait la même chose en C à la main depuis longtemps, et être même capable de faire des contributions valables au langage.
Et le jour ou un programmeur stockera un poiteur vers un objet de manière un peu cryptée ou utilisera une variable entière dont la valeure est la même que l'adresse d'un objet qui traine quelque part, le Bohem GC va se planter et l programmeur aurra une surprise...
J'admet que le premier cas relève d'une connerie de la part du programmeur, mais le deuxième est tout à fait réaliste.