Martin C. Martin wrote a great post on performance and dynamic languages. I particularly loved this quote:
Premature optimization is the root of all evil. Why am I forced to optimize when I am choosing my language, before writing a single line of code?
The post and comments are both well worth a read. I'm frustrated myself about the performance of dynamic languages, and while I don't particularly like the idea of annotating the programs to speed them up, I am a strong believer in designing dynamic languages to make the job easier for a compiler when it can be done without making things harder for the users. Optional type annotation, though can definitively be in that category if done right.
That said, I also believe that the compilers
can be made smart enough. I do have some ideas on making Ruby run at near native speeds, for example, and I plan on writing more about that later. They are still ideas, though, and given the amazing efforts of
the Rubinius team and others, hopefully I won't have to actually try to implement them...
Overall, the best approaches to improving the speed of dynamic languages seem to be to use stats and analysis to guess a lot of static properties or semi-static properties of the program, and then cop out and include a full JIT code generator in the runtime system in order to be able to reverse various optimizations or fall back on a "slow path" when your assumptions were wrong. In Ruby at least, which is the dynamic language I know best, there is plenty of room to do that, and it's also pretty close to the approach the
Rubinius team is taking with their "send sites", and also to what Smalltalk VM's do (which is where Rubinius got it frm).
I believe a lot of those techniques can be carried over in a "mostly static" native compiler (I'm sure it already has, but I haven't had nearly as much time as I'd like to read up on the work that's been done in that area), and hope to eventually get some chance to explore that (some of you may be aware that I'm posting a
series on writing a compiler in Ruby - what I've posted so far is trivial stuff, but towards the end of the parts I've written but not yet posted it's getting close to being what I want in a toy platform for experimentation with stuff like this)