> Ton benchmark ne prouve qu'une chose
Ah bon ca prouve qqch, les micro-benchs? Je croyais que ça voulait rien dire.
> 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.
> ce benchmark ne veut absolument rien dire
C'est pas ce que j'ai répété dans presque tous mes posts en haut? 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"
> les benchs c'est pratique quand tu veux prouver qqch
ou quand tu veux juste avoir une idée vague des performances d'une implémentation d'un langage sous certaines conditions.
> 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.
> 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)
> Avec quelque classes génériques, tu obtient les avantage de la gestion manuelle et des GC. Dans les zones qui n'ont pas être rapide, tu peux utiliser la libération automatique, les auto pointer... Et dans les zones critiques tu utilises une gestion manuelle et des pool automatique quand c'est nécéssaire.
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.
> 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.
> 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.)
> 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.
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.
[^] # 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é à 3.
> Ton benchmark ne prouve qu'une chose
Ah bon ca prouve qqch, les micro-benchs? Je croyais que ça voulait rien dire.
> 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.
> ce benchmark ne veut absolument rien dire
C'est pas ce que j'ai répété dans presque tous mes posts en haut? 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"
> les benchs c'est pratique quand tu veux prouver qqch
ou quand tu veux juste avoir une idée vague des performances d'une implémentation d'un langage sous certaines conditions.
> 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.
> 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)
> Avec quelque classes génériques, tu obtient les avantage de la gestion manuelle et des GC. Dans les zones qui n'ont pas être rapide, tu peux utiliser la libération automatique, les auto pointer... Et dans les zones critiques tu utilises une gestion manuelle et des pool automatique quand c'est nécéssaire.
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.
> 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.
> 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.)
> 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.
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.