Je sais bien, mais c'est le benchmark initial qui était complètement stupide, je n'ai fait que suivre les instructions! (calculer 500 fois la somme des 1/n2 pour n = 1 à 10000).
Du coup, un bon compilo s'apercevrait qu'on ne fait rien, je pense, et le test concerne tout autant le langage que le compilateur.
Le code initial en R incluait une double boucle, comme si c'était du C. Du coup, R mettait 3h à faire ce calcul stupide, ce qui n'est pas étonnant. Ce que j'ai essayé de montrer, c'est que ça n'était pas de la faute de R, mais du programmeur. Codé correctement, cet algo stupide est tout aussi rapide que du C.
Après, il existe forcément des algorithmes pour lesquels R est beaucoup plus lent que C. C'est évident, c'est un langage interprété. Mais il existe aussi de nombreux cas où en pratique R sera plus rapide que le code C, parce qu'il appelle des routines optimisées. Je ne connais pas les rouages internes de R, mais il est très efficace pour les opérations vectorisées (apply, lapply, sapply, etc), et ça ne m'étonnerait pas qu'il implémente des optimisations de bas niveau pour ça. Il est aussi diaboliquement bon pour des casse-têtes algorithmiques (par exemple tirer au hasard des éléments d'un vecteur avec ou sans remise avec pondération, avec une vitesse que je n'ai jamais réussi à approximer en C++).
Encore une fois, les langages sont tous Turing compplets, on peut tout faire avec n'importe quoi. Mais il est malsain de penser que de tout coder en C montre qu'on est un programmeur balèze. Ça montre juste qu'on est un programmeur qui ne connait que le C :)
[^] # Re: suckless !! More is less !
Posté par arnaudus . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 3.
Je sais bien, mais c'est le benchmark initial qui était complètement stupide, je n'ai fait que suivre les instructions! (calculer 500 fois la somme des 1/n2 pour n = 1 à 10000).
Du coup, un bon compilo s'apercevrait qu'on ne fait rien, je pense, et le test concerne tout autant le langage que le compilateur.
Le code initial en R incluait une double boucle, comme si c'était du C. Du coup, R mettait 3h à faire ce calcul stupide, ce qui n'est pas étonnant. Ce que j'ai essayé de montrer, c'est que ça n'était pas de la faute de R, mais du programmeur. Codé correctement, cet algo stupide est tout aussi rapide que du C.
Après, il existe forcément des algorithmes pour lesquels R est beaucoup plus lent que C. C'est évident, c'est un langage interprété. Mais il existe aussi de nombreux cas où en pratique R sera plus rapide que le code C, parce qu'il appelle des routines optimisées. Je ne connais pas les rouages internes de R, mais il est très efficace pour les opérations vectorisées (apply, lapply, sapply, etc), et ça ne m'étonnerait pas qu'il implémente des optimisations de bas niveau pour ça. Il est aussi diaboliquement bon pour des casse-têtes algorithmiques (par exemple tirer au hasard des éléments d'un vecteur avec ou sans remise avec pondération, avec une vitesse que je n'ai jamais réussi à approximer en C++).
Encore une fois, les langages sont tous Turing compplets, on peut tout faire avec n'importe quoi. Mais il est malsain de penser que de tout coder en C montre qu'on est un programmeur balèze. Ça montre juste qu'on est un programmeur qui ne connait que le C :)