Are dynamic languages slower than static languages? [closed]

Question

Are dynamic languages slower than static languages because, for example, the run-time has to check the type consistently?

Panda

Answer 1

All other things being equal, usually, yes.

Chibcha

Er, but, languages aren't fast or slow! See the answer by @Jorg ... – Ravel

Perhaps if the question has the word "Execution Engine", then the below answer would be marked. – Xray

Answer 2

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.

Roseanneroseate

Nice answer but I disagree with the your proposal about money. Money is not an inherent requirement, so it fails as a measurement. I even would disagree if you chose "effort". – Belia

Nice theories, but the reality disagrees with you : techempower.com/benchmarks/#section=data-r9 . All of the top performing frameworks in bechnmarks are in statically typed languages (C++/Java), and all the dynamic languages are way at the bottom. I'm not interested in hearing the no true scotsman fallacy, I'm interested in reality. – Teary

@ClickUpvote: That's not what I get from that data at all. First off, this does not show how dynamic languages perform compared to static languages. It shows how a very small number of specific versions of specific implementations of specific languages on a very small number of specific implementations of specific benchmarks running on a very small number of specific versions of specific implementations of specific operating systems on a very small number of specific implementations of specific hardware platforms perform. For example, it is well known that operating systems and CPUs with … – Wachtel

… virtual memory (such as Linux, Windows and OSX, and x86, AMD64, PowerPC, SPARC, MIPS, ARM, etc.) are absolutely deadly for performance of garbage-collected languages. It is also well-known that the techniques which are used in x86 CPUs to reduce the cost of memory operations do not work very well for object-oriented languages. So, this puts languages like C or C++ at a very unfair advantage. In order to be fair, they should add something like the Azul JCA with its Vega-3 CPU to the list, which is a CPU and hardware platform specifically designed for garbage-collected object-oriented … – Wachtel

… languages. Also, I don't see how "all the dynamic languages are way at the bottom". For example, in the JSON benchmark, of the bottom 20, 13 are static languages, and Lua is in the top 10. Also, if performance were related to "staticness", the two "most static" languages in this test, Haskell and Ur should be consistently at the top, but they aren't. In fact, they are not only outperformed by some "less static" static languages but many dynamic ones as well! In the Data Updates benchmark, the top 4 are dynamic languages (PHP and ECMAScript), Java is only at 8 and C++ at 30, outperformed by … – Wachtel

… PHP, ECMAScript, Python and Dart. For Ruby, AFAICS, they chose one of the slowest Ruby implementations (YARV), whereas for Java, they chose one of the fastest (Oracle HotSpot). This also doesn't seem particularly fair. Some of the fastest dynamic language implementations in existence are missing, such as some of the commercial high-performance CommonLisps and Smalltalks. – Wachtel

This answer is like someone asking : "Are cars faster than humans?" And you answer with "Well, it really depends, is the car broken? Or is the human in another car? Or does the human have a rocket pack on … " clever... – Beachlamar

@trilogy: No, it's like someone asking "Are blue cars faster than red cars", and answering that the color of the car doesn't matter, what matters is how the concept of "car" is implemented, what the conditions of the race are (a landrover will lose to a F1 car on a race track, but win in a forest), and how you measure "faster" (top speed, average speed, do you include tank stops or not, …) For example, there is a Ruby module that has both a C and a pure-Ruby implementation. TruffleRuby runs a benchmark using the pure-Ruby version faster than YARV runs the same benchmark using the C … – Wachtel

… implementation. According to the logic of many of the answers and comments of this question, that means that Ruby is faster than C and dynamic languages are faster than static languages. – Wachtel

Again, "are cars faster than humans" and you answered, "it depends". The marked answer is way more correct than your answer and more concise. Your answer serves no utility. benchmarksgame-team.pages.debian.net/benchmarksgame Most if not all statically typed and/or statically compiled languages run in order of magnitudes faster than their dynamic brethren. – Beachlamar

@trilogy: The question is non-sensical. A language is a piece of paper, it is an abstract set of mathematical rules and restrictions. Asking whether one language is slower than another language doesn't even make sense. In order to execute a program written in some language, that language has to be implemented somehow. As soon as the language is implemented, you can use that implementation to execute your program, but the performance is a property of the implementation, not the language. – Wachtel

@trilogy: Here is a very simple proof that shows that performance is not a property of the language: GCC has command line switches for optimization. If it were indeed true that performance were an inherent property of a language, then those command line switches cannot possibly have an impact on performance, since the language is still the same. The fact that those switches exist, and that they do influence performance, shows that performance cannot possibly be a property of the language. – Wachtel

@JörgWMittag thanks. I think we all know what he meant. – Beachlamar

@JörgWMittag that’s exactly what the marked answer stated. “With all things being equal”. Yours is a non-answer; no utility. – Beachlamar

Answer 3

First you must clarify whether you consider

• dynamic typing vs. static typing or
• 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.

EDIT

If you want numbers, I suggest you look at the The Computer Language Benchmarks. I found it insightful.

Basle

Of course, only the typing distinction applies to languages -- the rest is implementation details. – Ravel

Answer 4

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.

Valeric

There are several reasons for this: 0) the C++ and Java programmers were students working under controlled conditions but the Python and Perl programmers were a self selected group from an Internet trawl working as long as they wished. – Sublittoral

@igouy: I still think the main thing is that you don't end up using such piss-poor data structures when you use Python/Perl/etc ... – Ravel

@SamB: So you think the STL or other C++ libraries are "piss-poor" in terms of speed? – Norrisnorrv

High level data structures are at the core of most high level languages, dynamic or static. It's the C/C++ people who do the bit twiddling. – Putnem

Answer 5

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

Forge

Answer 6

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.

Northnorthwest

Answer 7

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.

Exciter

Answer 8

Reasonable to assume as more things need to be computed in runtime.

Tympany

"Reasonable to assume" doesn't really answer anything, does it? The poster of the question probably already assumed it and tried to verify that assumption ... – Ruler

Answer 9

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

Dorr