> Tester une série d'opération arithmétique n'est pas intéressant (ça donne si les test sont
> bien fait, les mêmes résultat,
Ben ça sert à quoi alors de compiler avec -O3 ?
Bon, quand on dit qu'on benchmark un langage, en fait, c'est clair qu'on benchmark un compilateur et l'environnement d'execution, mais bon.
Tu écrit
x = y + z;
t = x + w;
a = b + c;
Maintenant, tu as
Déjà pour un langage interprêté, pour faire y + z, il faut faire un switch sur l'opérateur (voire un appel de fonction), voir que c'est un "+", puis l'executer. Donc, si tu as les mêmes performances en lisp interprêté et en C, y'a de quoi se poser des questions.
Ensuite, est-ce que y et z sont passés par valeur ou par référence. En Java, si x et z sont des "Integer", il faut deux indirections de pointeurs. Ca coûte cher !
En Ada, y + z fait un test de débordement et lève potentiellement une exception (sauf si tu l'as désactivé à la compilation), pas en C.
Maintenant, entre deux compilateurs C.
Tu as celui qui a géré n'importe comment ses registres, qui a mis y et z dans la mémoire, et puis celui qui a mieux optimisé ses registres, et qui a déjà y et z dans des registres. Hop, on économise deux instructions "load".
Ensuite, tu as le compilateur con qui compile tout ça dans l'ordre, et qui est obligé d'attendre que x = y + z; soit fini pour commencer t = x + w; et celui qui a remarqué qu'en executant à la place
x = y + z;
a = b + c;
t = x + w;
On avait la même sémantique, mais qu'on utilisait mieux le pipelining du processeur. Et oui, le même ensemble d'instructions assembleurs ne s'executent pas à la même vitesse selon l'ordre dans lequel elles passent. Fait du pas à pas avec gdb dans du code compilé avec "-g -O3", tu verras que le curseur revient parfois en arrière.
Maintenant, tu as raison sur le fait qu'il y a bien d'autre choses à benchmarker. (les parcours de tableaux par exemple, c'est un cas d'école en matière de compilateur optimiseur).
[^] # Re: Comparaison de neuf langages sur un micro-benchmark
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Comparaison de neuf langages sur un micro-benchmark. Évalué à 8.
> bien fait, les mêmes résultat,
Ben ça sert à quoi alors de compiler avec -O3 ?
Bon, quand on dit qu'on benchmark un langage, en fait, c'est clair qu'on benchmark un compilateur et l'environnement d'execution, mais bon.
Tu écrit
x = y + z;
t = x + w;
a = b + c;
Maintenant, tu as
Déjà pour un langage interprêté, pour faire y + z, il faut faire un switch sur l'opérateur (voire un appel de fonction), voir que c'est un "+", puis l'executer. Donc, si tu as les mêmes performances en lisp interprêté et en C, y'a de quoi se poser des questions.
Ensuite, est-ce que y et z sont passés par valeur ou par référence. En Java, si x et z sont des "Integer", il faut deux indirections de pointeurs. Ca coûte cher !
En Ada, y + z fait un test de débordement et lève potentiellement une exception (sauf si tu l'as désactivé à la compilation), pas en C.
Maintenant, entre deux compilateurs C.
Tu as celui qui a géré n'importe comment ses registres, qui a mis y et z dans la mémoire, et puis celui qui a mieux optimisé ses registres, et qui a déjà y et z dans des registres. Hop, on économise deux instructions "load".
Ensuite, tu as le compilateur con qui compile tout ça dans l'ordre, et qui est obligé d'attendre que x = y + z; soit fini pour commencer t = x + w; et celui qui a remarqué qu'en executant à la place
x = y + z;
a = b + c;
t = x + w;
On avait la même sémantique, mais qu'on utilisait mieux le pipelining du processeur. Et oui, le même ensemble d'instructions assembleurs ne s'executent pas à la même vitesse selon l'ordre dans lequel elles passent. Fait du pas à pas avec gdb dans du code compilé avec "-g -O3", tu verras que le curseur revient parfois en arrière.
Maintenant, tu as raison sur le fait qu'il y a bien d'autre choses à benchmarker. (les parcours de tableaux par exemple, c'est un cas d'école en matière de compilateur optimiseur).