I understand that IronPython is an implementation of Python on the .NET platform just like IronRuby is an implementation of Ruby and F# is more or less OCaml.
What I can't seem to grasp is whether these languages perform closer to their "ancestors" or closer to something like C# in terms of speed. For example, is IronPython somehow "compiled" down to the same bytecode used by C# and, therefore, will run just as fast?
IronPython and IronRuby are built on top of the DLR -- dynamic language runtime -- and are compiled to CIL (the bytecode used by .NET) on the fly. They're slower than C# but faaaaaaar faster than their non-.NET counterparts. There aren't any decent benchmarks out there, to my knowledge, but you'll see the difference.
Currently IronRuby is pretty slow in most regards. It's definitely slower than MRI (Matz' Ruby Implementation) overall, though in some places they're faster.
IronRuby does have the potential to be much faster, though I doubt they'll ever get near C# in terms of speed. In most cases it just doesn't matter. A database call will probably make up 90% of the overall duration of a web request, for example.
I suspect the team will go for language-completeness rather than performance first. This will allow you to run IronRuby & run most ruby programs when 1.0 ships, then they can improve perf as they go.
I suspect IronPython has a similar story.
IronPython is actually the fastest Python implementation out there. For some definition of "fastest", at least: the startup overhead of the CLR, for example, is huge compared to CPython. Also, the optimizing compiler IronPython has, really only makes sense, when code is executed multiple times.
IronRuby has the potential to be as fast IronPython, since many of the interesting features that make IronPython fast, have been extracted into the Dynamic Language Runtime, on which both IronPython and IronRuby (and Managed JavaScript, Dynamic VB, IronScheme, VistaSmalltalk and others) are built.
In general, the speed of a language implementation is pretty much independent of the actual language features, and more dependent on the number of engineering man-years that go into it. IOW: dynamic vs. static doesn't matter, money does.
E.g., Common Lisp is a language that is even more dynamic than Ruby or Python, and yet there are Common Lisp compilers out there that can even give C a run for its money. Good Smalltalk implementations run as fast as Java (which is no surprise, since both major JVMs, Sun HotSpot and IBM J9, are actually just slightly modified Smalltalk VMs) or C++. In just the past 6 months, the major JavaScript implementations (Mozilla TraceMonkey, Apple SquirrelFish Extreme and the new kid on the block, Google V8) have made ginormous performance improvements, 10x and more, to bring JavaScript head-to-head with un-optimized C.
You've got the right idea by assuming that the performance of a modern .NET implementation will be between that of the ancestor and of C#. The reason is that C# is very closely matched to .NET itself.
F# is a no-brainer because C# and OCaml have similar performance characteristics themselves.
IronPython is much harder because Python and C# have wildly different performance characteristics. In fact, the answer depends upon the IronPython implementation itself, which will strive to convert inefficient Python-style evaluation into efficient C#-style evaluation whenever possible. Expect IronPython to be generally a lot slower than C# with the occassional spikes into the same territory. You can see this effect here.
Cheers, Jon Harrop.