Andrew Stopford's Weblog

It's not the point of Mono to hold off other people writing free software. Parrot will continue as long as its developers and users are having fun writing it, regardless of Mono running dynamic languages or not.
Languages like python and perl won't run faster on the CLR than with their respective C implementations, for the same reason that C code won't beat hand-optimized assembly code. So the question is: how much slower? Of course if it's too slow it's unusable. Jython is said to run from .70% to 10 times slower than CPython. A python running on the CLR is expected to run at least the same and probably quite a bit faster. The activestate implementation might have been a false start or there was not enough time for them to optimize it.
The perl slowdown factor would probably be a little higher, since the perl internals are really complex and require tons of special case handling code.
Changes to the CLR or otimizations in the dynamic languages runtimes could improve the numbers with time. At the end of the day a mean slowdown over the C implementation less then 2-3x is perfectly acceptable, for the same reason we accept that C code is slower than asm: easier coding, better interoperability. If more speed is needed, critical routines can be written in C# or IL: since C# code is 10 times faster than the perl/python one the overall run time won't change much.
So, performance is not the only issue, though it's important, if you need speed the existing C implementations are the best bet (and certainly parrot will be the fastest way to run perl 6 code).
The key issue is interoperability between different languages. Now, given this assumption, what is the best way to allow interoperability between dynamic languages and static typed ones? Parrot will probably be able to run both python and perl code, but what about C, C# and the like? If (and this is a really big if) Parrot will be able to C# code, it will be at least 10 or 30 times slower than the CLR (because of the complexity required by IL code). This is assuming Parrot maintains the current architecture (which I think it will). Will that be more acceptable than a 2-3 slowdown you'd get on the CLR for languages like python and perl that are already slow? Consider than in the CLR, if subsets of the existing python/perl code are too slow, you can use another high level langauge that is very fast like C#. On Parrot you can only go with a loadable extension implemented in C, losing portability and ease of deployment.
In the end I think Parrot will have perl and python implementations running together, maybe with the python code beating the CPython engine (we'll see who takes the cake on his face:-). The CLR will have somewhat slower python and perl implementations, but they will interoperate with C#, IL, VB.NET, mercury etc.

Thanks for the commnets Paolo, don't get me wrong its not that I was saying that Mono will hold off other people writing free software but that as a VM Parrot seems to offer more than the CLR (now I am not saying that for certain but the dynamnic languages issue is a big one and one the CLR has yet to address). I would love to hear Dans comments on the points you raised, Dan if your listening.....

Can anyone tell me why C# on Parrot will be "10x-30x slower than CLR?" I haven't seen a justification for that, as Parrot supports many of the static language features, and could run some variation of C# more dynamic features, like reflection. As a matter of fact, it was made to handle things like that specificially. I think that if you can reduce C# down to an IL, with an available grammar, you could produce PASM code that has reasonable performance, esp. if optimizations are used.

I lack much knowledge of C#, as I have only browsed a few books listing its features/semantics, so I would appreciate any feedback about why we would get a slowdown on Parrot, causing a speed deficit that's as big as the difference between pure Java bytecode and hand-optimized assembly.