Amos Wenger a écrit 91 commentaires

Forcément que l'écart se resserre, on a déjà coupé les bras et les jambes d'ooc pour donner une chance a C++!

Et puis bon, heu, écart resserré... 12% plus rapide quand meme, c'est pas rien il me semble.

Allez, rajoutons un sac de pierres sur le dos d'ooc: [http://ooc.pastebin.com/m512a5d78]

Et pourtant il ne bronche pas:

tsubaka ooc_tmp_nogc_if # time ../../withgc/newbench_cxx_O1

real 0m8.014s
user 0m7.907s
sys 0m0.006s
tsubaka ooc_tmp_nogc_if # time ./newbench_O1_nogc_if

real 0m7.376s
user 0m7.228s
sys 0m0.006s
tsubaka ooc_tmp_nogc_if # time ../../withgc/newbench_cxx_O2

real 0m6.842s
user 0m6.738s
sys 0m0.005s
tsubaka ooc_tmp_nogc_if # time ./newbench_O2_nogc_if

real 0m5.943s
user 0m5.890s
sys 0m0.005s


Brave bête, ooc, brave bête.

Tu propose d'écrire un vrai benchmark? Bien volontiers =) Envoie-moi les sources quand tu auras fini.

J'ai déjà moi-même dit et répété qu'un micro-benchmark ne voulait pas dire grand-chose. En revanche, celui-la est intéressant, puisque (en tout cas dans ses dernieres incarnations) il mesure juste la différence de surpoids (overhead) entre ooc et C++ dans l'implémentation des classes.

Ensuite, en ce qui concerne la granularité de la heap et la gestion des alignement, je ne suis pas du tout spécialiste dans ce domaine, mais il me semble que GNU G++ et GNU GCC ne devraient pas gérer les choses trop différemment, non? (même backend..)

Je rappelle au grand public que le compilateur ooc génère du C ensuite compilé par GCC. Je pense qu'on peut donc considérer ces derniers micro-benchmarks comme des combats "à la loyale".

En théorie, je suis assez d'accord. En pratique par contre, ça te (nous) contredit et j'avoue que ça me surprend moi-même.


tsubaka ooc_tmp_nogc # time ../../withgc/newbench_cxx_O1_nono

real 0m8.151s
user 0m8.134s
sys 0m0.011s
tsubaka ooc_tmp_nogc # time ./newbench_O1_nogc

real 0m7.125s
user 0m6.999s
sys 0m0.005s
tsubaka ooc_tmp_nogc # time ../../withgc/newbench_cxx_O2_nono

real 0m6.684s
user 0m6.609s
sys 0m0.046s
tsubaka ooc_tmp_nogc # time ./newbench_O2_nogc

real 0m5.954s
user 0m5.823s
sys 0m0.042s


En passant, si d'autres personnes pouvaient faire tourner ces benchmarks sur leur machine, histoire de confirmer/infirmer les résultats, ça serait vraiment sympa.

C'est pas faux.

Bon ben il me reste plus qu'a implémenter un switch "-nogc" dans le compilateur ooc et tout le monde sera content?

Super question, merci =)

J'ai moi-meme eu ce probleme, puisque pour le projet pour lequel j'ai ecrit ooc, l'enonce encourageait a utiliser GLUI (librairie graphique d'interface utilisateur en C++). J'ai donc du me lancer dans les joies de la compilation jointe de code C et C++ (sans avoir son main dans un .cxx), et c'est horrible. Et j'ai du écrire toutes les méthodes à la main.

En revanche, en pratique, rien n'empêche d'améliorer le compilateur ooc pour qu'il comprenne les headers C++ et permette l'utilisation de leurs classes/fonctions. Moi c'est plus la compatibilité binaire qui m'inquiète (entre le C et le C++), parce que oui, le C++ n'a pas d'ABI standard, bien sur...

Si assez de personnes sont intéressées par l'utilisation transparente de librairies C++ en ooc, je me pencherais volontiers sur le problème, même si je préfèrerais voir fleurir des ports en ooc de librairies C++ ;)

[http://linuxfr.org/comments/1044014.html#1044014]

Et maintenant?

Pour avoir un élément de comparaison valide, j'ai manuellement modifié le code C produit par ooc pour enlever toute référence au garbage collector, c'est a dire supprimer les appels a GC_init, remplacer les appels a GC_malloc() par malloc(), et ajouter free().

Et comme on pouvait s'y attendre.... ooc est quand meme plus rapide que C++.
Je suppose qu'on peut en déduire qu'ooc implémente les classes de manière plus légère que le C++, mais je vous laisse vous faire votre propre conclusion.

Résultats:

tsubaka ooc_tmp # time ../../withgc/newbench_cxx_O1

real 0m7.903s
user 0m7.829s
sys 0m0.008s
tsubaka ooc_tmp # time ./newbench_O1_nogc

real 0m6.427s
user 0m6.309s
sys 0m0.008s
tsubaka ooc_tmp # time ../../withgc/newbench_cxx_O2

real 0m6.847s
user 0m6.737s
sys 0m0.004s
tsubaka ooc_tmp # time ./newbench_O2_nogc

real 0m5.976s
user 0m5.855s
sys 0m0.002s


Code C généré par ooc avant modification (utilise le GC): http://ooc.pastebin.com/m1a579233

Code C généré par ooc après modification (utilise malloc/free): http://ooc.pastebin.com/m48d21e05

Même argumentation, encore et encore. Si c'est pour utiliser C++ avec aucune des possibilités qui le rendent plus lent que le C, alors pourquoi utiliser C++?

Bon pour continuer:

> Maintenant si tu te renseignais sur le C++ tu verrais que question performances il est strictement à égalité avec le C

Ce n'est pas honnete. Si on utilise C++ exactement comme le C, alors, oui, comme le C++ est presque un superset du C, alors on a les memes performances.

Ce qui m'interesse dans les comparaisons c'est la performance qu'on a en faisant les choses comme le langage les recommande. Et si, en C++ on utilise la STL, et qu'en C on utilise des pointeurs a tout va, je suis désolé mais on a pas du tout les mêmes performances. Voir la première partie du benchmark sur cette page: [http://unthought.net/c++/c_vs_c++.html]

C'est rigolo parce que j'avais prévu cette remarque.

Malheureusement, tu aurais pu le constater par toi-même si tu avais fait l'effort de télécharger ooc et de compiler le benchmark.

Voici donc les résultats avec -O2, dans les deux cas.

Résultats:

tsubaka tmp # time ./newbench_cxx_O1
real 0m8.439s
user 0m8.354s
sys 0m0.004s
tsubaka tmp # time ./newbench_O1
real 0m3.402s
user 0m3.301s
sys 0m0.012s
tsubaka tmp # time ./newbench_cxx_O2
real 0m6.911s
user 0m6.790s
sys 0m0.007s
tsubaka tmp # time ./newbench_O2
real 0m2.813s
user 0m2.767s
sys 0m0.005s
tsubaka tmp #


Makefile:

all:
g++ newbench.cxx -o newbench_cxx_O1
ooc newbench
mv newbench newbench_O1
g++ newbench.cxx -O2 -o newbench_cxx_O2
ooc newbench -backend=gcc,-O2
mv newbench newbench_O2


Bah je dirais plutot que "C est un langage ou tout est presque gratuit mais tu te démerdes tout seul, ok?" et que "C++ est un langage pour lequel une fois que tu a l'abonnement, tu paies que ce que tu utilises (mais tarif double, pour des raisons de gestion interne)".

Et puis comme je me lasse de me répéter, je vais citer Wikipédia pour changer, a propos des GC: "Many consider the penalty very small compared to the benefits it brings." [http://en.wikipedia.org/wiki/Garbage_collection_(computer_sc(...)]

Pour les fuites mémoires, heu, moui, moyen, je ne sais pas quelle est la complexité des structures de données des programmes que tu as du écrire en C, m'enfin il me semblait que même de très bon programmeurs devaient réfléchir a deux fois avant de gérer tout correctement.

Quant a Valgrind, excellent outil, je l'utilise régulièrement pour résoudre des problèmes plus sérieux que des fuites (violation d'accès mémoire).

J'ai rien contre ajouter l'option de désactiver le GC dans ooc, mais ca servirait strictement a rien, tout le SDK est codé dans l'esprit "on s'occupe pas de libérer la mémoire", donc dans ce cas là autant coder en C.

Faut savoir choisir son langage, pour la tache qu'on a à accomplir. Qu'est-ce que tu penserais de quelqu'un qui se mettrait a utiliser du Java sur des téléphones mobiles ? (Oh, mais.. attendez.. ils le font.. Bizarre. Vraiment.)

* pour des sites anglophones, meme.

hum.

C'est dur de répondre professionellement à la mauvaise fois.

Déjà, tu pars du principe que C et C++ sont les deux langages les plus rapides. Notre cher LupusMic objecterait que tu confond langage et implémentation, et il aurait raison.

Mais.. désolé de te décevoir. Comme example, les programmes écrits en Fortran sont généralement plus rapides (je laisse Google te rassurer sur ce point.)

Ensuite, il y a des benchmark réels (je lis pas de bouquins sur les performances moi, je télécharge et compile les benchmarks existant) qui confirment ce que Pierre Bourdon dit.
Pour pypy, c'est par ici: [http://morepypy.blogspot.com/2008/01/rpython-can-be-faster-t(...)]
Pour Java, c'est par la: [http://kano.net/javabench/]
Et pour ooc, un peu plus bas dans cette page (mais c'est un microbench assez insignifiant dans la discussion,)

A noter que, comme ooc est traduit en C, ça n'a pas beaucoup de sens de "comparer les performances d'ooc a C", mais plutôt de "comparer malloc/free au Boehm GC".

Après, toute la question est: est-ce que parce que tel ou tel programme, sous telle charge de travail, tourne 2% moins vite qu'une "implémentation optimale" (au passage, tu me donneras l'URL d'une "implémentation optimale" de n'importe quel programme, parce que moi, je n'en ai jamais vu), c'est terriblement dramatique et ça va provoquer la chute en bourse de la boîte pour laquelle tu codes.

En revanche, plusieurs parmi les gourous du développement s'accordent pour dire que le temps de développement requis pour un programme dans un certain programme est plus significatif qu'une faible différence de performance. Voir: [http://www.paulgraham.com/langdes.html] (en particulier la section "Speed comes from profilers", mais tout l'essai est tres intéressant)

Tiens ben d'ailleurs, je me trompe, donc je me corrige: on peut overloader new en C++.
Voir: [http://www.bearcave.com/software/c++_mem.html]

En revanche, je vous met au défi d'implémenter un memory allocator meilleur que celui de votre implémentation C++ par défaut.

...

Je suis d'accord pour me faire démonter mon microbench, mais seulement si le démontage est techniquement correct.

En l'occurence... quelqu'un pourrait-il m'expliquer en quoi auto_ptr, shared_ptr, et autres joyeusetés du genre ont de commun avec un vrai garbage collector tel qu'on peut trouver dans Java (et oui c'est une référence, voir le nouveau collector G1 dans le JRE 1.6u14), python, etc. ou dans n'importe quel langage un tant soit peu haut niveau?

Si par gestion automatique de mémoire tu entends "libérer la mémoire quand on sort du scope", alors oui forcément, a ce compte la, le C++ est garbage collecté...

Quant a std::allocator, je cherche, mais je ne vois vraiment pas ce qu'il vient faire la. A ma connaissance, non, new n'utilise pas std::allocator, et on ne peut pas reimplementer new comme on veut en C++ (dites-moi si je me trompe).

Quand a dire que mon microbench n'a aucun valeur eh bien.. il a aussi peu de valeur que n'importe quel microbench: il teste effectivement l'implementation GNU g++ 4.3 du C++ contre GNU gcc 4.3 du ooc/C avec le Boehm GC v7.1 sous Gentoo Linux en ce qui concerne l'allocation d'objets et leur destruction. Cependant, c'est représentatif des performances qu'obtiendront les utilisateurs d'un de ces langages "out-of-the-box". Je pense qu'il est donc tout de même digne d'intérêt.

J'avoue, utiliser le Boehm GC était a l'époque de cette décision, une solution de facilité. Pour la prochaine implémentation (voir [http://github.com/amoswenger/rock]), je considère sérieusement d'écrire un GC non-conservatif (puisque plus le temps passe, plus ooc est strictement typé.)

Pour ce qui est de l'usage d'un gc (peu importe lequel) en temps réel, je n'ai jamais entendu/vu ça. URL, please.

Ooooooooooooh très juste. Je l'avais oublié celui-là, Je retiens mieux les langages avec des couleurs [http://www.dangermouse.net/esoteric/piet.html].

Tiens d'ailleurs, je l'ai refait vite fait.

Resultats:

tsubaka tmp # time ./newbench_cxx

real 0m8.048s
user 0m7.859s
sys 0m0.011s
tsubaka tmp # time ./newbench

real 0m3.322s
user 0m3.279s
sys 0m0.011s
tsubaka tmp #


Makefile:

all:
g++ newbench.cxx -o newbench_cxx
ooc newbench


C++:

class Dummy {

private:
int i;

public:
Dummy();
void increment();

};

Dummy::Dummy() {

this->i = 0;

}

void Dummy::increment() {

this->i++;

}

int main() {

for(int i = 0; i < 100000000; i++) {
Dummy* d = new Dummy();
d->increment();
delete d;
}

}


ooc:

class Dummy {

Int i = 0;

func increment { i++; }

}

func main {

for(Int i: 0..100_000_000) {
new Dummy.increment;
}

}



Comme tous les benchmarks, a prendre avec des pincettes.

C'est une idée reçue malheureusement très répandue. La vérité est un peu plus complexe.

Sur un test réalisé par curiosité, la création de 1'000'000+ petits objets dans une boucle est environ 2x plus rapide en ooc qu'en C++ (qui n'utilise pas de GC, donc). Ces résultats, bien que peu fiables, confirment les études faites sur la performance des garbage collectors.

En pratique, une application qui alloue beaucoup de petits objets souvent tournera bien plus vite avec un garbage collector. En contraste, une application qui alloue peu de très gros objets tournera mieux en gestion de mémoire manuelle.

Pour de plus amples informations sur ce sujet, des diapos et documents expliquant les avantages/désavantages, je ne peux que vous référer a la page du GC utilisé par ooc: [http://www.hpl.hp.com/personal/Hans_Boehm/gc/]

J'y travaille depuis une semaine. Je suis pas sur que ma moitié sera du même avis (les femmes ne nous comprennent vraiment pas). Je ne peux pourtant pas me permettre de faire tache sur les photos entre Guido et Larry.
Mais de toute façon, Bjarne fait son rebelle, il se rase, lui!

(eh oui, meme linuxfr se vend.. scandaleux, mais ou va le monde, etc.)

Ha oui, bien vu le coup des source a source ObjC. Sont-ils bien aussi bien maintenus/compatibles que les compilateurs plus standards?

Mais non t'es pas lourd. Les mecs lourd c'est "c'est pas LISP/Ruby/Python/Scala/D/C#"

Donc oui ma foi tu as fort raison, le SDK pourrait être un peu plus documenté. En l'occurence, j'utilise une notation a la javadoc dans les sources, donc par ici tu devrais trouver ton bonheur: [http://github.com/amoswenger/ooc/tree/4a977fe092e18bd9cdaffe663b1519905deb0d23/sdk/structs]

1000 fois désolé pour le manque de doc, j'ai déjà passé 2 nuits de suite a écrire le language reference guide, donc le reste viendra en son temps =)

coin? [http://hules.free.fr/wmcoincoin]