Oui oui tout le monde sait que python/JS sont aussi rapide que du C++, bien sûr.
Dans les 15-20 dernières années, d'après un membre du Fraunhofer Institut spécialisé dans le domaine, les cacluls numériques utilisés en météorologie sont devenus a3 fois plus rapides (de mémoire a ≈ 1000) où les processeurs sont responsables d'un facteur a et les algorithmes d'un facteur a2. Cela signifie qu'un ordinateur vieux de 15 ans utilisant les algorithmes d'aujourd'hui est a ≈ 1000 fois plus rapide qu'un ordinateur d'aujourd'hui utilisant les algorithmes d'il y a 15 ans. Pour aller le plus vite possible il faut donc privilégier l'expressivité du langage — qui va permettre de retravailler les algorithmes avec le plus de souplesse possible — à sa proximité avec la machine.
De plus les processeurs ont des propriétés rendant la comparaison des vitesses d'éxécution de deux variantes d'un même programme impossible^H très difficile, le but étant de la répondre à la question «l'accélération de 90% de mon programme est-elle due à mon patch?» Les processeurs sont, pour faire court, très sensible à la position du code et des données en mémoire, pour plus de détails voir l'article d'Emery et son abondante bibliographie:
À cause de ces deux faits, la recherche de la rapidité est certainement la dernière des raisons pourlaquelle on doit s'intéresser aux langages de bas niveau, du moins en ce qui concerne le calcul.
Ceci dit, lorsqu'une application desktop rame, la cause serait selon moi plutôt à rechercher dans l'utilisation inappropriée d'un appel système, d'une base de données, ou d'un format de sérialisation inapdaté pour échanger des données (genre XML, utilisé beaucoup plus souvent qu'il ne le devrait: si on ne s'intéresse pas à la validation autant utiliser un format plus léger comme les S-expression ou JSON). Relier dans ce domaine la lenteur d'éxécution au langage utilisé relève plus la naïveté que d'autre chose.
[^] # Re: Qtisation
Posté par Michaël (site web personnel) . En réponse à la dépêche Ubuntu 13.04 Raring Ringtail. Évalué à 10. Dernière modification le 28 avril 2013 à 01:55.
Dans les 15-20 dernières années, d'après un membre du Fraunhofer Institut spécialisé dans le domaine, les cacluls numériques utilisés en météorologie sont devenus a3 fois plus rapides (de mémoire a ≈ 1000) où les processeurs sont responsables d'un facteur a et les algorithmes d'un facteur a2. Cela signifie qu'un ordinateur vieux de 15 ans utilisant les algorithmes d'aujourd'hui est a ≈ 1000 fois plus rapide qu'un ordinateur d'aujourd'hui utilisant les algorithmes d'il y a 15 ans. Pour aller le plus vite possible il faut donc privilégier l'expressivité du langage — qui va permettre de retravailler les algorithmes avec le plus de souplesse possible — à sa proximité avec la machine.
De plus les processeurs ont des propriétés rendant la comparaison des vitesses d'éxécution de deux variantes d'un même programme impossible
^Htrès difficile, le but étant de la répondre à la question «l'accélération de 90% de mon programme est-elle due à mon patch?» Les processeurs sont, pour faire court, très sensible à la position du code et des données en mémoire, pour plus de détails voir l'article d'Emery et son abondante bibliographie:http://www.cs.umass.edu/~emery/pubs/stabilizer-asplos13.pdf
À cause de ces deux faits, la recherche de la rapidité est certainement la dernière des raisons pourlaquelle on doit s'intéresser aux langages de bas niveau, du moins en ce qui concerne le calcul.
Ceci dit, lorsqu'une application desktop rame, la cause serait selon moi plutôt à rechercher dans l'utilisation inappropriée d'un appel système, d'une base de données, ou d'un format de sérialisation inapdaté pour échanger des données (genre XML, utilisé beaucoup plus souvent qu'il ne le devrait: si on ne s'intéresse pas à la validation autant utiliser un format plus léger comme les S-expression ou JSON). Relier dans ce domaine la lenteur d'éxécution au langage utilisé relève plus la naïveté que d'autre chose.