Ton benchmark ne prouve qu'une chose, le C++ est plus lent que OOC quand tu lui demande de faire quelque chose de stupide et qu'en plus tu le fait mal.
Il n'y a aucun interet au programme que tu montre et même pire, c'est une des plus mauvaise manière de faire cete chose sans interet. Lorsque un objet doit être alloué et libéré très rapidement et en très grande quantité, la bonne manière de faire est d'utiliser un pool d'objet, tout comme en C quand tu dois allouer et libérer un très grand nombre de petites zones mémoire, tu en alloue un gros paquet d'un coup que tu libère aussi en une fois à la fin.
Tu pourras dire ce que tu veux, ce benchmark ne veut absolument rien dire. La seule bonne manière de faire un benchmark, indépendament du test lui même, c'est déjà de bien connaître les deux langages, et d'écrire un bon code pour chacun d'eux.
Il suffit de regarder les résultats du shoutout pour s'en rendre compte, certains langages se retrouvent à la traine, non pas car ils sont réellement moins bon, mais uniquement car les benchs ont étés codés n'importe comment.
Les benchs c'est super pratique, quand tu veux prouver quelque chose, en cherchant bien tu finis toujours par en trouver un qui approte la preuve que tu veux. Par contre dans la réalité, trouve moi un seul code qui fait quelque chose d'aussi stupide que ton bench.
Dans la réalité, tu ne fait pas juste un ++ sur variable de ton objet mais tu fais un traîtement qui justifie la création de cet objet, donc l'allocation/libération à beaucoup moin d'impact sur les perfs et l'écart ce réduit.
Ensuite dans la réalité, tu fais un profile de ton code et tu t'apperçois que cette gestion mémoire continue d'avoir un impact sur les perf, donc tu utilises un pool, et là, la version OOC n'a plus rien pour elle.
Sur un exemple comme le tien, l'utilisation d'un pool permet d'exploser les perfs de OOC très simplement. Le nombre d'objets est connu à la base donc un seul malloc/free est nécessaire dans toutes la durée du programme.
Moralité, même le programme OOC me semble écrit avec les pieds, lui aussi méritrait l'utilisation d'un pool ;-)
[^] # 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.
Il n'y a aucun interet au programme que tu montre et même pire, c'est une des plus mauvaise manière de faire cete chose sans interet. Lorsque un objet doit être alloué et libéré très rapidement et en très grande quantité, la bonne manière de faire est d'utiliser un pool d'objet, tout comme en C quand tu dois allouer et libérer un très grand nombre de petites zones mémoire, tu en alloue un gros paquet d'un coup que tu libère aussi en une fois à la fin.
Tu pourras dire ce que tu veux, ce benchmark ne veut absolument rien dire. La seule bonne manière de faire un benchmark, indépendament du test lui même, c'est déjà de bien connaître les deux langages, et d'écrire un bon code pour chacun d'eux.
Il suffit de regarder les résultats du shoutout pour s'en rendre compte, certains langages se retrouvent à la traine, non pas car ils sont réellement moins bon, mais uniquement car les benchs ont étés codés n'importe comment.
Les benchs c'est super pratique, quand tu veux prouver quelque chose, en cherchant bien tu finis toujours par en trouver un qui approte la preuve que tu veux. Par contre dans la réalité, trouve moi un seul code qui fait quelque chose d'aussi stupide que ton bench.
Dans la réalité, tu ne fait pas juste un ++ sur variable de ton objet mais tu fais un traîtement qui justifie la création de cet objet, donc l'allocation/libération à beaucoup moin d'impact sur les perfs et l'écart ce réduit.
Ensuite dans la réalité, tu fais un profile de ton code et tu t'apperçois que cette gestion mémoire continue d'avoir un impact sur les perf, donc tu utilises un pool, et là, la version OOC n'a plus rien pour elle.
Sur un exemple comme le tien, l'utilisation d'un pool permet d'exploser les perfs de OOC très simplement. Le nombre d'objets est connu à la base donc un seul malloc/free est nécessaire dans toutes la durée du programme.
Moralité, même le programme OOC me semble écrit avec les pieds, lui aussi méritrait l'utilisation d'un pool ;-)