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++).
C'est pas R le langage ou le runtime qui est rapide, ce sont les libs d'algèbre linéaire qu'il y a dessous (et je prends le pari que c'est du C).
Ça serait aussi con que de dire que Python est rapide par ce que Numpy est rapide. Python est lent comme une loutre bourrée. Toutes les libs d'algèbre linéaire & co sortent des runtimes classiques pour chopper un bon gros buffer mémoire et faire leur sauce dans leur coin (cf. la discussion plus bas sur ce genre de besoin).
Bref R en tant qu'outil est rapide. Maintenant venir dire que les langages dynamiques, interprétés ou autre c'est cool pour la perf faut pas déconner. Tu t'en sers juste comme glue. Si tu vas à l'aéroport en velo, c'est pas lui qui te fait traversé l'atlantique en 5h...
[^] # Re: suckless !! More is less !
Posté par ckyl . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 8.
C'est pas R le langage ou le runtime qui est rapide, ce sont les libs d'algèbre linéaire qu'il y a dessous (et je prends le pari que c'est du C).
Ça serait aussi con que de dire que Python est rapide par ce que Numpy est rapide. Python est lent comme une loutre bourrée. Toutes les libs d'algèbre linéaire & co sortent des runtimes classiques pour chopper un bon gros buffer mémoire et faire leur sauce dans leur coin (cf. la discussion plus bas sur ce genre de besoin).
Bref R en tant qu'outil est rapide. Maintenant venir dire que les langages dynamiques, interprétés ou autre c'est cool pour la perf faut pas déconner. Tu t'en sers juste comme glue. Si tu vas à l'aéroport en velo, c'est pas lui qui te fait traversé l'atlantique en 5h...