Les micro-benchmark, c'est le design pattern TrollFactory
Langage C, gcc -O3
int calcul(int n) {return (((n==0)||n==1)?1:calcul(n-1)+calcul(n-2));}
int main(int argc, char *argv[]) {calcul(44);}
real 0m14.293s
user 0m14.265s
sys 0m0.015s
Java
public class Fibo {
public static int calcul(int n) {return (((n==0)||n==1)?1:calcul(n-1)+calcul(n-2)); }
public static void main(String[] args){calcul(44);}
}
real 0m10.494s
user 0m0.015s
sys 0m0.015s
Interprétation naïve génératrice de Troll : Java est plus rapide que C
En fait, en faisant un programme en C plus sioux qui stocke les résultats intermédiaires dans une pile on arrive a des perfs équivalentes ou meilleures (j'ai la flemme de faire le prog, mais j'ai déjà essayé), de même le programme est écrit sous forme récursive, mais
Langage C linéaire, gcc -O3
int main(int argc, char *argv[]) {
int iteration,fibo,n=1,n_1=1;
for (iteration=3;iteration<44;iteration++) {fibo = n +n_1; n_1=n;n=fibo;}
return (fibo);
}
real 0m0.024s
user 0m0.030s
sys 0m0.031s
Java Linéaire
public class Fibolin {
public static void main(String[] args){
int iteration,fibo=1,n=1,n_1=1;
for (iteration=3;iteration<44;iteration++) {fibo = n +n_1; n_1=n;n=fibo;}
}}
real 0m0.136s
user 0m0.015s
sys 0m0.015s
Finallement, on retient :
- Il faut toujours choisir l'algorithme le moins naïf, si ce n'est pas couteux pour la conception du programme (shell sort contre bubble sort par ex pour 2 tri sans appels de piles)
- Il faut choisir le langage qui offre le meilleur compromis paresse du programmeur/rapidité d'éxecution.
Franchement, je ne connais pas Erlang, mais pour faire des agents distribués concurrents, je pense que j'aurais un résultat concret et plus fiable plus rapidement en apprenant Erlang et sa méthode de pensée, que de le coder en pur C.
Et puis ces discours étaient les mêmes dans les années 90 entre l'asm et le C sur 68k/80x86 :-))) et le C a gagné, cas son niveau d'abstraction ;-) permet d'être plus productif que de l'asm pur.
<μTroll>
Vive l'ASM et les démo framerate 60fps sur amiga et les démos ST sont pourries :-)))) (je dis ça par nostalgie, tout le monde est mort maintenant !)
</μTroll>
[^] # Comment casser le mythe de rapidité de Fibonacci :-)
Posté par darkleon . En réponse à la dépêche Erlang/OTP R11B supporte les architectures multiprocesseur. Évalué à 10.
Langage C, gcc -O3
Java
Interprétation naïve génératrice de Troll : Java est plus rapide que C
En fait, en faisant un programme en C plus sioux qui stocke les résultats intermédiaires dans une pile on arrive a des perfs équivalentes ou meilleures (j'ai la flemme de faire le prog, mais j'ai déjà essayé), de même le programme est écrit sous forme récursive, mais
Langage C linéaire, gcc -O3
Java Linéaire
Finallement, on retient :
- Il faut toujours choisir l'algorithme le moins naïf, si ce n'est pas couteux pour la conception du programme (shell sort contre bubble sort par ex pour 2 tri sans appels de piles)
- Il faut choisir le langage qui offre le meilleur compromis paresse du programmeur/rapidité d'éxecution.
Franchement, je ne connais pas Erlang, mais pour faire des agents distribués concurrents, je pense que j'aurais un résultat concret et plus fiable plus rapidement en apprenant Erlang et sa méthode de pensée, que de le coder en pur C.
Et puis ces discours étaient les mêmes dans les années 90 entre l'asm et le C sur 68k/80x86 :-))) et le C a gagné, cas son niveau d'abstraction ;-) permet d'être plus productif que de l'asm pur.
<μTroll>
Vive l'ASM et les démo framerate 60fps sur amiga et les démos ST sont pourries :-)))) (je dis ça par nostalgie, tout le monde est mort maintenant !)
</μTroll>