sont des langues dynamiques plus lentes que les langues statiques car, par exemple, le temps d'exécution doit vérifier le type de manière cohérente?
9 Réponses :
Toutes les autres choses étant égales, généralement oui.
Euh, mais, les langues ne sont pas rapides ou lentes! Voir la réponse par @jorg ...
Peut-être que si la question a le mot "moteur d'exécution", la réponse ci-dessous serait marquée.
raisonnable d'assumer car plus de choses doivent être calculées en runtime.
"Raisonnable de supposer" ne répond pas vraiment à rien, n'est-ce pas? L'affiche de la question probablement déjà l'a déjà supposée et a essayé de vérifier cette hypothèse ...
Les horaires de langue dynamique n'ont besoin que de vérifier le type occasionnellement .
Mais c'est toujours, typiquement plus lent.
Il y a des gens de bonnes affirmations selon lesquelles ces lacunes de performance sont toutefois attaquables. par exemple. http://steve-yegge.blogspot.com/ 2008/05 / Dynamic-Langues-Strike-Back.html
Tout d'abord, vous devez préciser si vous envisagez
habituellement nous voulons dire
, mais ce n'est pas nécessaire le cas.
Type Les informations peuvent aider la machine virtuelle à expédier le message plus rapidement que les informations de type Witout, mais la différence tendent à disparaître avec optimisation dans la machine virtuelle qui détectent les sites d'appel monomorphes . Voir le paragraphe «Considération de performance» dans ce Poste sur l'invocation dynamique .
Les débats entre la compilée et interprété par rapport à l'octet-code JIT sont toujours ouverts. Certains soutiennent que Bytecode JIT entraîne une exécution plus rapide que la compilation régulière car la compilation est plus précise en raison de la présence de plus d'informations collectées au moment de l'exécution. Lire le Entrée Wikipedia sur JIT pour plus de perspicacité. La langue interprétée est effectivement plus lente que l'une des deux formes ou compilation.
Je ne discuterai pas plus loin et je voudrais commencer une discussion chauffée, je voulais juste souligner que l'écart entre les deux a tendance à devenir plus petits et plus petits. Les chances sont que le problème de performance que vous pourriez affronter ne sera pas lié à la langue et à la machine virtuelle, mais à cause de votre conception.
Si vous voulez numéros , je vous suggère de regarder le Les repères de la langue de l'ordinateur . J'ai trouvé cela perspicace.
Bien sûr, seule la distinction de frappe s'applique aux langues - le reste est des détails de la mise en œuvre.
Non, les langues dynamiques ne sont pas nécessairement plus lentes que les langues statiques.
Le pyyfollant et Les projets PSYCO ont déployé beaucoup de progrès sur la construction de compilateurs JIT pour Python ayant une compilation axée sur les données; En d'autres termes, ils compileront automatiquement des versions de fonctions fréquemment appelées spécialisées pour des valeurs communes particulières d'arguments. Non seulement par type, comme un modèle C ++, mais des valeurs d'argumentation réelles; Disons qu'un argument est généralement zéro ou aucun, puis il y aura une version spécifiquement compilée de la fonction pour cette valeur.
Ceci peut conduire à un code compilé plus rapide que vous ne sortirez d'un compilateur C ++, et puisque cela le fait au moment de l'exécution, il peut découvrir des optimisations spécifiquement pour les données d'entrée réelles pour cette instance particulière du programme.
Non.
Les langues dynamiques ne sont pas plus lentes que les langues statiques. En fait, il est impossible pour tout langage , dynamique ou non, d'être plus lent qu'une autre langue (ou plus rapide, tout simplement parce qu'une langue n'est qu'une tasse de règles mathématiques abstraites. Vous ne pouvez pas exécuter un tas de règles mathématiques abstraites, ils ne peuvent donc jamais être lents (er) ou rapides (er).
L'affirmation selon laquelle "les langages dynamiques sont plus lentes que les langues statiques" ne sont pas seulement mauvais , il ne fait même pas sens . Si l'anglais était une langue dactylographiée, cette déclaration ne serait même pas typée.
Pour qu'une langue soit même capable de exécuter , il doit être mis en œuvre premier. maintenant Vous pouvez mesurer les performances, mais vous ne mesurez pas les performances de la langue , vous mesurez les performances de l'exécution moteur . La plupart des langues ont de nombreux moteurs d'exécution différents, avec des caractéristiques de performance très différentes. Pour C, par exemple, la différence entre les implémentations les plus rapides et les plus lisses est un facteur de 100 000 ou plus!
En outre, vous ne pouvez pas vraiment mesurer les performances d'un moteur d'exécution, soit: vous devez écrire un code sur exécuter sur ce moteur d'exection en premier. Mais maintenant, vous ne mesurez pas les performances du moteur d'exécution, vous ne mesurez pas les performances du code de référence . Qui a très peu de choses à voir avec la performance du moteur d'exécution et certainement rien à voir avec la performance de la langue .
En général, le fonctionnement du code bien conçu sur des moteurs d'exécution hautes performances bien conçus donnera à peu près la même performance, indépendamment du fait que la langue est statique ou dynamique, de procédure, orientée objet ou fonctionnelle, impérative ou déclarative, paresseuse ou strict, pur ou impur.
En fait, je proposerais que la performance d'un système dépendait uniquement de la quantité d'argent consacrée à ce que cela soit rapide et complètement indépendant de toute discipline de frappe particulière, paradigme de programmation ou langue.
Prenons par exemple SmallTalk, Lisp, Java et C ++. Tous sont, ou ont été à un moment donné, la langue de choix pour le code haute performance. Tous ont énormes les quantités d'ingénierie et de recherche des siècles de l'homme qui leur sont dépensées pour les rendre rapides. Tous ont des moteurs d'exécution commerciaux hautement performants hautement réglées disponibles. Compte tenu du même problème, mis en œuvre par des développeurs grossièrement comparables, ils fonctionnent tous à peu près les mêmes.
Deux de ces langues sont dynamiques, deux sont statiques. Java est intéressant, car mais il s'agit d'une langue statique, la plupart des implémentations de haute performance modernes sont en réalité Dynamic mises en œuvre. (En fait, plusieurs JVM de haute performance moderne sont en fait soit SmallTalk VMS sous déguisement, dérivé de Smalltalk VMS ou écrit par SmallTalk VM Entreprises.) LISP est également intéressant, car mais bien que ce soit une langue dynamique, il y en a certains (bien que peu nombreux ) Des implémentations statiques hautes performances.
Et nous n'avons même pas commencé à parler du de l'environnement d'exécution: les systèmes d'exploitation multimédias modernes, les processeurs traditionnels et les architectures matériels traditionnels sont fortement biaisés vers des langues statiques, au point d'être activement activement. hostile pour les langages dynamiques. Étant donné que les environnements d'exécution des ordinateurs traditionnels modernes sont à peu près un scénario les plus stricts pour les langues dynamiques, il est tout à fait étonnant à quel point ils sont réellement performants et que l'on ne peut imaginer que ce que la performance dans un environnement moins hostile ressemblerait.
Belle réponse mais je suis en désaccord avec la proposition de votre offre d'argent. L'argent n'est pas une exigence inhérente, de sorte qu'il échoue comme une mesure. Je n'aurais même pas d'accord si vous avez choisi un "effort".
Belles théories, mais la réalité n'est pas d'accord avec vous: TechEMPower.com/benchmarks/#section= Data-R9 . Tous les cadres supérieurs de la performance de Bechnmarks sont dans des langues typées statiquement (C ++ / Java) et toutes les langues dynamiques sont en bas en bas. Je ne suis pas intéressé à entendre le véritable escalier, je suis intéressé par la réalité.
@ClickUPVote: Ce n'est pas ce que je reçois de ces données du tout . Tout d'abord, cela ne montre pas comment les langues dynamiques se produisent par rapport aux langues statiques. Il montre comment un très petit nombre de versions spécifiques de mises en œuvre spécifiques de langues spécifiques sur un très petit nombre d'implémentations spécifiques de références spécifiques fonctionnant sur un très petit nombre de versions spécifiques d'implémentations spécifiques de systèmes d'exploitation spécifiques sur un très petit nombre de données spécifiques. Les implémentations de plates-formes matérielles spécifiques sont effectuées. Par exemple, il est bien connu que les systèmes d'exploitation et les CPU avec ...
... la mémoire virtuelle (telle que Linux, Windows et OSX, et X86, AMD64, PowerPC, SPARC, MIPS, BRARC, ETC) sont absolument mortels pour la performance des langues collectées à la poubelle. Il est également connu que les techniques utilisées dans X86 CPU pour réduire le coût des opérations de mémoire ne fonctionnent pas très bien pour les langues orientées objet. Cela met donc des langues comme c ou C ++ à un avantage très injuste. Pour être juste, ils devraient ajouter quelque chose comme l'Azul JCA avec son CPU Vega-3 à la liste, une plate-forme matérielle et une plate-forme matérielle spécialement conçue pour les orientés orientées objet à la poubelle ...
... langues. En outre, je ne vois pas comment "toutes les langues dynamiques sont globalement en bas". Par exemple, dans la référence JSON, du bas 20, 13 sont des langues statiques et Lua est également dans le top 10. En outre, si la performance était liée à la "statique", les deux langues "la plus statique" de ce test, HASKELL et Ur devrait être systématiquement en haut, mais ils ne sont pas. En fait, ils sont non seulement surperformés par des langues statiques "moins statiques", mais de nombreux types dynamiques aussi! Dans la référence de la mise à jour des données, les 4 premières sont des langues dynamiques (PHP et ECMAScript), Java n'est qu'à 8 et C ++ à 30, surperformé par ...
... PHP, ECMAScript, Python et Dart. Pour Ruby, Afaics, ils ont choisi l'une des implémentations rubis les plus lentes (YARV), alors que pour Java, ils ont choisi l'un des hotspot (Oracle Hotspot). Cela ne semble pas non plus particulièrement juste. Certaines des implémentations linguistiques dynamiques les plus rapides d'existence sont manquantes, telles que certaines des commonlis et des smalltals commerciaux de haute performance.
Cette réponse est comme si quelqu'un demande: "Les voitures sont-elles plus rapides que les humains?" Et vous répondez avec "Eh bien, cela dépend vraiment, la voiture est-elle cassée? Ou est-ce que l'homme dans une autre voiture? Ou est-ce que l'homme a un pack de fusées sur ..." intelligent ... "
@Trilogy: Non, c'est comme si quelqu'un demande "les voitures bleues plus rapides que les voitures rouges" et répondant à ce que la couleur de la voiture n'a pas d'importance, quelle est la manière dont le concept de "voiture" est mis en œuvre, quelles conditions de La race est (un Landrover perdra une voiture F1 sur une piste de course, mais gagne dans une forêt) et comment vous mesurez «plus rapide» (vitesse supérieure », vitesse moyenne, incluez-vous des arrêts de réservoirs ou non, ...) Par exemple, Il y a un module rubis qui a à la fois un C et une implémentation pure-rubis. TruffleLy est une référence en utilisant la version pure-rubis plus rapidement que YARV gère le même point de repère utilisant le ...
… la mise en oeuvre. Selon la logique de nombreuses réponses et commentaires de cette question, cela signifie que Ruby est plus rapide que c et dynamiques langues sont plus rapides que les langues statiques.
Encore une fois, "sont des voitures plus rapides que les humains" et vous avez répondu "Cela dépend". La réponse marquée est bien plus correcte que votre réponse et plus concise. Votre réponse ne sert aucun utilitaire. Benchmarksgame-team.pages.debian.net/benchmarksgame La plupart sont tous statistiques dactylographiés et / ou des langues compilées statiquement exécutées dans l'ordre des magnitudes plus rapidement que leurs frères dynamiques.
@Trilogie: La question n'est pas sensicale. Une langue est un morceau de papier, c'est un ensemble abstrait de règles mathématiques et de restrictions. Demander si une langue est plus lente qu'une autre langue n'a même pas de sens. Afin d'exécuter un programme écrit dans une langue, cette langue doit être mise en œuvre d'une manière ou d'une autre. Dès que la langue est mise en œuvre, vous pouvez utiliser cette implémentation pour exécuter votre programme, mais la performance est une propriété de la mise en œuvre , pas la langue.
@Trilogy: Voici une preuve très simple qui montre que la performance n'est pas une propriété de la langue: GCC a des commutateurs de ligne de commande pour l'optimisation. S'il était vrai que la performance était une propriété inhérente d'une langue, ces commutateurs de ligne de commande ne peuvent pas avoir d'impact sur la performance, car la langue est toujours la même. Le fait que ces commutateurs existent et qu'ils font performances influencent, montre que la performance ne peut éventuellement être une propriété de la langue.
@ Jörgwmittag merci. Je pense que nous savons tous ce qu'il voulait dire.
@ Jörgwmittag c'est exactement ce que la réponse marquée a déclaré. "Avec toutes choses étant égales". Le vôtre est une réponse non-réponse; Pas d'utilité.
Le facteur important de Themost est d'envisager l'algorithme d'expédition de la méthode. Avec des langues statiques, chaque méthode est généralement attribuée à un index. Les noms que nous voyons dans la source ne sont pas réellement utilisés au moment de l'exécution et sont à la source à des fins de lecture de lecture. Naturellement, des langues comme Java les gardent et les rendent disponibles en réflexion, mais en termes de quand on invoque une méthode non utilisée. Je laisserai la réflexion et la liaison de cette discussion. Cela signifie qu'une méthode est invoquée, le Runtmne utilise simplement le décalage pour rechercher une table et un appel. Une langue dynamique d'autre part utilise le nom de la fonction pour rechercher une carte, puis appelle ladite fonction. Un hashmap va toujours être plus lent que d'utiliser une recherche d'index dans un tableau.
En fait, il est difficile de dire parce que nombre des points de repère utilisés ne sont pas ce représentant. Et avec des environnements d'exécution plus sophistiqués, comme Hotspot JVM, les différences deviennent de moins en moins pertinentes. Jetez un coup d'œil à l'article suivant:
Théorie et pratique Java: compilation dynamique et mesure de la performance < / a>
Au niveau des instructions Les implémentations actuelles de langues dactylographiées dynamiquement sont généralement plus lentes que les implémentations actuelles de langues typées statiquement.
Cependant, cela ne signifie pas nécessairement que la mise en œuvre d'un programme sera plus lente dans les langues dynamiques - il existe de nombreux cas documentés du même programme mis en œuvre dans une langue statique et dynamique et que la mise en œuvre dynamique s'est avérée être plus rapide. Par exemple Cette étude (PDF) a donné le même problème aux programmeurs dans une variété de langues et comparé le résultat. Le temps d'exécution moyen des implémentations Python et Perl était plus rapide que l'exécution moyenne pour les implémentations C ++ et Java.
Il y a plusieurs raisons à cela:
1) Le code peut être mis en œuvre plus rapidement dans une langue dynamique, laissant plus de temps pour l'optimisation.
2) Les structures de données de haut niveau (cartes, ensembles, etc.) sont une partie centrale de la plupart des langues dynamiques et sont donc plus susceptibles d'être utilisées. Depuis qu'ils sont noyau de la langue, ils ont tendance à être très optimisés.
3) La compétence de programmeur est plus importante que la vitesse linguistique - Un programmeur inexpérimenté peut écrire un code lent dans n'importe quelle langue. Dans l'étude mentionnée ci-dessus, il y avait plusieurs ordres de différence de magnitude entre la mise en œuvre la plus rapide et la plus lente dans chacune des langues.
4) Dans de nombreux domaines de problèmes, la vitesse d'exécution est dominée par des E / S ou un autre facteur externe à la langue.
5) Le choix de l'algorithme peut choisir un choix de langues nain. Dans le livre "Plus de perles de programmation", Jon Bentley a mis en place deux algorithmes pour un problème - l'un était O (n ^ 3) et mis en œuvre dans un fortrange optimisé sur une crayon1. L'autre était O (n) et mis en œuvre en basique sur une Micro à domicile TRS80 (c'était dans les années 1980). Le TRS80 a surperformé la crayon 1 pour N> 5000.
Il y a plusieurs raisons à cela: 0) Les programmeurs C ++ et Java étaient des étudiants travaillant dans des conditions contrôlées, mais les programmeurs Python et Perl étaient un groupe auto-sélectionné d'un chalut Internet travaillant aussi longtemps qu'ils le souhaitaient.
@Igouy: Je pense toujours que l'essentiel est que vous ne finissez pas de telles structures de données Piss-Piss, lorsque vous utilisez Python / Perl / etc ...
@Samb: Vous pensez donc que les bibliothèques STL ou d'autres bibliothèques C ++ sont "Piss-pauvres" en termes de vitesse?
Les structures de données de haut niveau sont au cœur de la plupart des langues de haut niveau, dynamiques ou statiques. C'est les personnes C / C ++ qui font le bit Twiddling.