我们甚至还没有开始谈论执行环境的其余部分：现代主流操作系统、主流 CPU 和主流硬件架构都严重偏向静态语言，甚至对动态语言充满敌意。语言。鉴于现代主流执行环境对于动态语言来说几乎是最坏的情况，它们的实际执行效果非常令人惊讶，人们只能想象在不那么敌对的环境中的性能会是什么样子。
No.
Dynamic languages are not slower than static languages. In fact, it is impossible for any language, dynamic or not, to be slower than another language (or faster, for that matter), simply because a language is just a bunch of abstract mathematical rules. You cannot execute a bunch of abstract mathematical rules, therefore they cannot ever be slow(er) or fast(er).
The statement that "dynamic languages are slower than static languages" is not only wrong, it doesn't even make sense. If English were a typed language, that statement wouldn't even typecheck.
In order for a language to even be able to run, it has to be implemented first. Now you can measure performance, but you aren't measuring the performance of the language, you are measuring the performance of the execution engine. Most languages have many different execution engines, with very different performance characteristics. For C, for example, the difference between the fastest and slowest implementations is a factor of 100000 or so!
Also, you cannot really measure the performance of an execution engine, either: you have to write some code to run on that exection engine first. But now you aren't measuring the performance of the execution engine, you are measuring the performance of the benchmark code. Which has very little to do with the performance of the execution engine and certainly nothing to do with the performance of the language.
In general, running well-designed code on well-designed high-performance execution engines will yield about the same performance, independent of whether the language is static or dynamic, procedural, object-oriented or functional, imperative or declarative, lazy or strict, pure or impure.
In fact, I would propose that the performance of a system is solely dependent on the amount of money that was spent making it fast, and completely independent of any particular typing discipline, programming paradigm or language.
Take for example Smalltalk, Lisp, Java and C++. All of them are, or have at one point been, the language of choice for high-performance code. All of them have huge amounts of engineering and research man-centuries expended on them to make them fast. All of them have highly-tuned proprietary commercial high-performance execution engines available. Given roughly the same problem, implemented by roughly comparable developers, they all perform roughly the same.
Two of those languages are dynamic, two are static. Java is interesting, because although it is a static language, most modern high-performance implementations are actually dynamic implementations. (In fact, several modern high-performance JVMs are actually either Smalltalk VMs in disguise, derived from Smalltalk VMs or written by Smalltalk VM companies.) Lisp is also interesting, because although it is a dynamic language, there are some (although not many) static high-performance implementations.
And we haven't even begun talking about the rest of the execution environment: modern mainstream operating systems, mainstream CPUs and mainstream hardware architectures are heavily biased towards static languages, to the point of being actively hostile for dynamic languages. Given that modern mainstream execution environments are pretty much of a worst-case scenario for dynamic languages, it is quite astonishing how well they actually perform and one can only imagine what the performance in a less hostile environment would look like.
statically compiled languaged vs. interpreted languages vs. bytecode JIT.
Usually we mean
dynamc language = dynamic typing + interpreted at run-time and
static languages = static typing + statically compiled
, but it's not necessary the case.
Type information can help the VM dispatch the message faster than witout type information, but the difference tend to disappear with optimization in the VM which detect monomorphic call sites. See the paragraph "performance consideration" in this post about dynamic invokation.
The debates between compiled vs. interpreted vs. byte-code JIT is still open. Some argue that bytecode JIT results in faster execution than regular compilation because the compilation is more accurate due to the presence of more information collected at run-time. Read the wikipedia entry about JIT for more insight. Interpreted language are indeed slower than any of the two forms or compilation.
I will not argue further, and start a heated discussion, I just wanted to point out that the gap between both tend to get smaller and smaller. Chances are that the performance problem that you might face will not be related to the language and VM but because of your design.
At the instruction level current implementations of dynamically typed languages are typically slower than current implementations of statically typed languages.
However that does not necessarily mean that the implementation of a program will be slower in dynamic languages - there are lots of documented cases of the same program being implemented in both a static and dynamic language and the dynamic implementation has turned out to be faster. For example this study (PDF) gave the same problem to programmers in a variety of languages and compared the result. The mean runtime for the Python and Perl implementations were faster than the mean runtime for the C++ and Java implementations.
There are several reasons for this:
1) the code can be implemented more quickly in a dynamic language, leaving more time for optimisation.
2) high level data structures (maps, sets etc) are a core part of most dynamic languages and so are more likely to be used. Since they are core to the language they tend to be highly optimised.
3) programmer skill is more important than language speed - an inexperienced programmer can write slow code in any language. In the study mentioned above there were several orders of magnitude difference between the fastest and slowest implementation in each of the languages.
4) in many problem domains execution speed it dominated by I/O or some other factor external to the language.
5) Algorithm choice can dwarf language choice. In the book "More Programming Pearls" Jon Bentley implemented two algorithms for a problem - one was O(N^3) and implemented in optimised fortran on a Cray1. The other was O(N) and implemented in BASIC on a TRS80 home micro (this was in the 1980s). The TRS80 outperformed the Cray 1 for N > 5000.
Themost important factor is to consider the method dispatch algorithm. With static languages each method is typically allocated an index. THe names we see in source are not actually used at runtime and are in source for readaility purposes. Naturally languages like java keep them and make them available in reflection but in terms of when one invokes a method they are not used. I will leave reflection and binding out of this discussion. This means when a method is invoked the runtmne simply uses the offset to lookup a table and call. A dynamic language on the other hand uses the name of the function to lookup a map and then calls said function. A hashmap is always going to be slower than using an index lookup into an array.
pypy 和 psyco 项目在构建具有数据驱动编译功能的 Python JIT 编译器方面取得了很大进展；换句话说，它们将自动编译专门用于参数的特定公共值的经常调用的函数的版本。不仅按类型（如 C++ 模板），还按实际参数值；假设一个参数通常为零或无，那么将有一个针对该值的函数的专门编译版本。
这可能会导致编译后的代码比从 C++ 编译器中获得的代码更快，并且由于它是在运行时执行此操作，因此它可以发现专门针对该特定程序实例的实际输入数据的优化。
No, dynamic languages are not necessarily slower than static languages.
The pypy and psyco projects have been making a lot of progress on building JIT compilers for python that have data-driven compilation; in other words, they will automatically compile versions of frequently called functions specialised for particular common values of arguments. Not just by type, like a C++ template, but actual argument values; say an argument is usually zero, or None, then there will be a specifically compiled version of the function for that value.
This can lead to compiled code that is faster than you'd get out of a C++ compiler, and since it is doing this at runtime, it can discover optimisations specifically for the actual input data for this particular instance of the program.
Actually, it's difficult to say because many of the benchmarks used are not that representative. And with more sophisticated execution environments, like HotSpot JVM, differences are getting less and less relevant. Take a look at following article:
发布评论
评论（9）
不会。
动态语言并不比静态语言慢。事实上，任何语言，无论是否动态，都不可能比另一种语言慢（或者就此而言更快），仅仅因为语言只是一堆抽象的数学规则。你无法执行一堆抽象的数学规则，因此它们永远不会慢（呃）或快（呃）。
“动态语言比静态语言慢”的说法不仅错误，甚至没有意义。如果英语是一种类型语言，那么该语句甚至不会进行类型检查。
为了让一种语言能够运行，它必须首先实现。 现在您可以衡量性能，但是您不是在衡量语言的性能，您是在衡量执行的性能引擎。。大多数语言都有许多不同的执行引擎，具有截然不同的性能特征。例如，对于 C 语言，最快和最慢的实现之间的差异是 100000 倍左右！
此外，您也无法真正测量执行引擎的性能：您必须首先编写一些代码在该执行引擎上运行。但现在您不是在测量执行引擎的性能，而是在测量基准代码的性能。这与执行引擎的性能关系不大，当然与语言的性能也没有关系。
一般来说，在精心设计的高性能执行引擎上运行精心设计的代码将产生大致相同的性能，无论语言是静态还是动态、过程性、面向对象还是函数式、命令式还是声明式、惰性还是严格，纯净或不纯净。
事实上，我认为系统的性能完全取决于为提高系统速度而花费的资金量，并且完全独立于任何特定的打字规则、编程范例或语言。
以 Smalltalk、Lisp、Java 和 C++ 为例。所有这些都是或曾经一度是高性能代码的首选语言。所有这些都花费了数百年的工程和研究时间来提高速度。它们都具有经过高度调整的专有商业高性能执行引擎。考虑到大致相同的问题，由大致相当的开发人员实现，它们的性能都大致相同。
其中两种语言是动态的，两种是静态的。 Java 很有趣，因为虽然它是一种静态语言，但大多数现代高性能实现实际上都是动态实现。 （事实上，一些现代的高性能 JVM 实际上要么是变相的 Smalltalk VM，源自 Smalltalk VM，要么是由 Smalltalk VM 公司编写的。） Lisp 也很有趣，因为虽然它是一种动态语言，但有一些（虽然不多） ）静态高性能实现。
我们甚至还没有开始谈论执行环境的其余部分：现代主流操作系统、主流 CPU 和主流硬件架构都严重偏向静态语言，甚至对动态语言充满敌意。语言。鉴于现代主流执行环境对于动态语言来说几乎是最坏的情况，它们的实际执行效果非常令人惊讶，人们只能想象在不那么敌对的环境中的性能会是什么样子。
No.
Dynamic languages are not slower than static languages. In fact, it is impossible for any language, dynamic or not, to be slower than another language (or faster, for that matter), simply because a language is just a bunch of abstract mathematical rules. You cannot execute a bunch of abstract mathematical rules, therefore they cannot ever be slow(er) or fast(er).
The statement that "dynamic languages are slower than static languages" is not only wrong, it doesn't even make sense. If English were a typed language, that statement wouldn't even typecheck.
In order for a language to even be able to run, it has to be implemented first. Now you can measure performance, but you aren't measuring the performance of the language, you are measuring the performance of the execution engine. Most languages have many different execution engines, with very different performance characteristics. For C, for example, the difference between the fastest and slowest implementations is a factor of 100000 or so!
Also, you cannot really measure the performance of an execution engine, either: you have to write some code to run on that exection engine first. But now you aren't measuring the performance of the execution engine, you are measuring the performance of the benchmark code. Which has very little to do with the performance of the execution engine and certainly nothing to do with the performance of the language.
In general, running well-designed code on well-designed high-performance execution engines will yield about the same performance, independent of whether the language is static or dynamic, procedural, object-oriented or functional, imperative or declarative, lazy or strict, pure or impure.
In fact, I would propose that the performance of a system is solely dependent on the amount of money that was spent making it fast, and completely independent of any particular typing discipline, programming paradigm or language.
Take for example Smalltalk, Lisp, Java and C++. All of them are, or have at one point been, the language of choice for high-performance code. All of them have huge amounts of engineering and research man-centuries expended on them to make them fast. All of them have highly-tuned proprietary commercial high-performance execution engines available. Given roughly the same problem, implemented by roughly comparable developers, they all perform roughly the same.
Two of those languages are dynamic, two are static. Java is interesting, because although it is a static language, most modern high-performance implementations are actually dynamic implementations. (In fact, several modern high-performance JVMs are actually either Smalltalk VMs in disguise, derived from Smalltalk VMs or written by Smalltalk VM companies.) Lisp is also interesting, because although it is a dynamic language, there are some (although not many) static high-performance implementations.
And we haven't even begun talking about the rest of the execution environment: modern mainstream operating systems, mainstream CPUs and mainstream hardware architectures are heavily biased towards static languages, to the point of being actively hostile for dynamic languages. Given that modern mainstream execution environments are pretty much of a worst-case scenario for dynamic languages, it is quite astonishing how well they actually perform and one can only imagine what the performance in a less hostile environment would look like.
在其他条件相同的情况下，通常是的。
All other things being equal, usually, yes.
首先，您必须澄清您是否考虑
通常我们的意思是
，但情况不一定如此。
类型信息可以帮助 VM 比没有类型信息的情况更快地分派消息，但随着 VM 中检测单态调用站点的优化，这种差异往往会消失。请参阅这篇有关动态调用的帖子中的“性能考虑”段落。
编译型、解释型和字节码 JIT 之间的争论仍然存在。一些人认为字节码 JIT 比常规编译执行速度更快，因为由于在运行时收集了更多信息，编译更加准确。阅读有关 JIT 的维基百科条目了解更多信息。解释性语言确实比这两种形式或编译中的任何一种都慢。
我不再争论，展开激烈的讨论，我只是想指出，两者之间的差距往往会越来越小。您可能面临的性能问题很可能与语言和虚拟机无关，而是与您的设计有关。
编辑
如果您想要数字，我建议您查看计算机语言基准。我发现它很有洞察力。
First you must clarify whether you consider
Usually we mean
, but it's not necessary the case.
Type information can help the VM dispatch the message faster than witout type information, but the difference tend to disappear with optimization in the VM which detect monomorphic call sites. See the paragraph "performance consideration" in this post about dynamic invokation.
The debates between compiled vs. interpreted vs. byte-code JIT is still open. Some argue that bytecode JIT results in faster execution than regular compilation because the compilation is more accurate due to the presence of more information collected at run-time. Read the wikipedia entry about JIT for more insight. Interpreted language are indeed slower than any of the two forms or compilation.
I will not argue further, and start a heated discussion, I just wanted to point out that the gap between both tend to get smaller and smaller. Chances are that the performance problem that you might face will not be related to the language and VM but because of your design.
EDIT
If you want numbers, I suggest you look at the The Computer Language Benchmarks. I found it insightful.
在指令级别，动态类型语言的当前实现通常比静态类型语言的当前实现慢。
然而，这并不一定意味着在动态语言中程序的实现会更慢——有很多记录在案的同一程序在静态和动态语言中实现的案例，并且动态实现速度更快。例如这项研究（PDF）给程序员带来了同样的问题并比较了多种语言的结果。 Python 和 Perl 实现的平均运行时间比 C++ 和 Java 实现的平均运行时间快。
这样做的原因有几个：
1）用动态语言可以更快地实现代码，从而留出更多时间进行优化。
2）高级数据结构（映射、集合等）是大多数动态语言的核心部分，因此更有可能被使用。由于它们是语言的核心，因此往往会被高度优化。
3）程序员的技能比语言速度更重要——没有经验的程序员可以用任何语言编写缓慢的代码。在上述研究中，每种语言的最快和最慢实现之间存在几个数量级的差异。
4) 在许多问题领域中，执行速度由 I/O 或语言外部的一些其他因素决定。
5）算法的选择会使语言的选择相形见绌。在“更多编程珍珠”一书中，Jon Bentley 针对一个问题实现了两种算法 - 一种是 O(N^3)，并在 Cray1 上用优化的 fortran 实现。另一种是 O(N)，在 TRS80 家用微控制器上用 BASIC 实现（这是在 20 世纪 80 年代）。当 N > 1 时，TRS80 的性能优于 Cray 1。 5000。
At the instruction level current implementations of dynamically typed languages are typically slower than current implementations of statically typed languages.
However that does not necessarily mean that the implementation of a program will be slower in dynamic languages - there are lots of documented cases of the same program being implemented in both a static and dynamic language and the dynamic implementation has turned out to be faster. For example this study (PDF) gave the same problem to programmers in a variety of languages and compared the result. The mean runtime for the Python and Perl implementations were faster than the mean runtime for the C++ and Java implementations.
There are several reasons for this:
1) the code can be implemented more quickly in a dynamic language, leaving more time for optimisation.
2) high level data structures (maps, sets etc) are a core part of most dynamic languages and so are more likely to be used. Since they are core to the language they tend to be highly optimised.
3) programmer skill is more important than language speed - an inexperienced programmer can write slow code in any language. In the study mentioned above there were several orders of magnitude difference between the fastest and slowest implementation in each of the languages.
4) in many problem domains execution speed it dominated by I/O or some other factor external to the language.
5) Algorithm choice can dwarf language choice. In the book "More Programming Pearls" Jon Bentley implemented two algorithms for a problem - one was O(N^3) and implemented in optimised fortran on a Cray1. The other was O(N) and implemented in BASIC on a TRS80 home micro (this was in the 1980s). The TRS80 outperformed the Cray 1 for N > 5000.
动态语言运行时只需偶尔检查类型。
但它通常仍然较慢。
然而，有些人声称这种绩效差距是可以克服的。例如 http://steve-yegge.blogspot.com /2008/05/dynamic-languages-strike-back.html
Dynamic language run-times only need to check the type occasionally.
But it is still, typically, slower.
There are people making good claims that such performance gaps are attackable, however; e.g. http://steve-yegge.blogspot.com/2008/05/dynamic-languages-strike-back.html
最重要的因素是考虑方法调度算法。对于静态语言，通常为每个方法分配一个索引。我们在源代码中看到的名称实际上并未在运行时使用，而是出于可读性目的而在源代码中使用。当然，像 java 这样的语言会保留它们并使其在反射中可用，但在调用方法时它们不会被使用。我将把反思和约束排除在这次讨论之外。这意味着当调用方法时，runtmne 仅使用偏移量来查找表并调用。另一方面，动态语言使用函数名称来查找映射，然后调用该函数。哈希映射总是比使用索引查找数组慢。
Themost important factor is to consider the method dispatch algorithm. With static languages each method is typically allocated an index. THe names we see in source are not actually used at runtime and are in source for readaility purposes. Naturally languages like java keep them and make them available in reflection but in terms of when one invokes a method they are not used. I will leave reflection and binding out of this discussion. This means when a method is invoked the runtmne simply uses the offset to lookup a table and call. A dynamic language on the other hand uses the name of the function to lookup a map and then calls said function. A hashmap is always going to be slower than using an index lookup into an array.
不，动态语言不一定比静态语言慢。
pypy 和 psyco 项目在构建具有数据驱动编译功能的 Python JIT 编译器方面取得了很大进展；换句话说，它们将自动编译专门用于参数的特定公共值的经常调用的函数的版本。不仅按类型（如 C++ 模板），还按实际参数值；假设一个参数通常为零或无，那么将有一个针对该值的函数的专门编译版本。
这可能会导致编译后的代码比从 C++ 编译器中获得的代码更快，并且由于它是在运行时执行此操作，因此它可以发现专门针对该特定程序实例的实际输入数据的优化。
No, dynamic languages are not necessarily slower than static languages.
The pypy and psyco projects have been making a lot of progress on building JIT compilers for python that have data-driven compilation; in other words, they will automatically compile versions of frequently called functions specialised for particular common values of arguments. Not just by type, like a C++ template, but actual argument values; say an argument is usually zero, or None, then there will be a specifically compiled version of the function for that value.
This can lead to compiled code that is faster than you'd get out of a C++ compiler, and since it is doing this at runtime, it can discover optimisations specifically for the actual input data for this particular instance of the program.
假设是合理的，因为需要在运行时计算更多的东西。
Reasonable to assume as more things need to be computed in runtime.
实际上，这很难说，因为使用的许多基准测试并不具有代表性。随着 HotSpot JVM 等更复杂的执行环境的出现，差异变得越来越不相关。请查看以下文章：
Java 理论与实践：动态编译和绩效衡量
Actually, it's difficult to say because many of the benchmarks used are not that representative. And with more sophisticated execution environments, like HotSpot JVM, differences are getting less and less relevant. Take a look at following article:
Java theory and practice: Dynamic compilation and performance measurement