- Clash of the Type Models
- The Question of Speed
- Availability
- Dynamic Languages Are Fun!
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The Question of Speed
Dynamic languages tend to be slow. It's nice to claim that Smalltalk and C run at the same speed, but it's pretty hard to make that happen, for a couple of reasons. The biggest reason is that Smalltalk and C encourage programmers to write different kinds of code. A subset of Smalltalk is used to implement the Squeak virtual machine that maps directly to C, and this runs at the same speed as the same code written in C. You could use it for Smalltalk programs, but then you'd lose most of the benefit of using Smalltalk.
Similarly, nothing stops you from implementing a Smalltalk-like dynamic dispatch mechanism on top of C and using it for all of your flow control. If you did this, however, you would almost certainly end up with slower code than if you'd just used Smalltalk, because a lot more people have spent time optimizing most Smalltalk implementations than optimizing your code.
If you write code in a dynamic style, a dynamic language is typically faster. If you write code in a static style, then a static language is almost always faster. One thing that has changed recently is that more programs are written in a dynamic style.
The most obvious form of dynamic behavior is loading code at runtime. If you want to support plug-ins or scripting, you need a degree of dynamic behavior. If you have a nice scripting environment, it becomes tempting to write more and more of your application in that environment. One of the goals of my Smalltalk implementation is to use it for both application development and scripting, so scripts added by the user run at the same speed as code written by the application author. This is quite common in games, where the graphics and physics code are written in a static language, but everything else is written on top of them in a dynamic language.
Another case is I/O-bound applications. A lot of applications that communicate over the network are limited by the network bandwidth—and, more importantly, by latency—than by CPU speed.
The speed of dynamic languages is constantly improving. Google's new V8 JavaScript engine includes a number of techniques borrowed from Self and Strongtalk, such as polymorphic inline caching and hidden class transforms. These have been around since the 1990s, but have only recently found mainstream use. Why? Because previously speed was not considered important for dynamic languages. Ruby still uses a directly interpreted abstract syntax tree—the slowest way of implementing a language—and yet Ruby is widely used.
Dynamic languages were dismissed as "scripting" languages for a long time, but developers are starting to implement complex programs in dynamic languages, and thus speed becomes more of a problem. These old techniques for speeding implementations are becoming more important, and people are starting to look at developing new techniques. In my next article, I'll discuss some ways in which future CPU designs could help to improve this situation.