IronPython supported in GIMP#

A few days ago I already blogged on my initial experiments with IronPython. Today I actually implemented the first plug-in written in Python for GIMP#. Currently it’s only available in CVS, but it will be part of GIMP# 0.12. This plug-in does a very straightforward calculation: it calculates the average color of an image and sets the complete image to this average value. I already wrote such a plug-in in C#. Massimo Perga has ported the plug-in to Java to show that we can support Java as well, using IKVM. And now we also support Python as a third language in GIMP#. Some observations:

I haven’t figured out yet how a Python class can inherit from an abstract C# base class. A quick and dirty solution is to introduce a non-abstract C# class in between to solve this. For the moment this works.

One has to do explicitly convert Python lists (for example the list with commandline arguments: sys.argv) to an Array in the .NET namespace. I hope that in future IronPython versions there will be implicit conversions.

I haven’t figured out yet if you can use anonymous delegates in IronPython. For the moment this is solved by introducing a couple of extra member functions

I still have to find out how you can compile a .py file without actually executing it!

One thing very annoying: somehow IronPython couldn’t see the difference between multiple overloads in one of my GIMP# functions. I had to give them explicit names in order to solve this😦

The best (or worst) bit I kept for the last: I did some performance measurements on the same plug-in written in C# and IronPython. Since they are so similar and they are both run on top of the CLI I would expect similar performance. However for this (micro) benchmark the C# implementation is 4 times as fast as the IronPython version (using Mono on Linux). I don’t have an explanation for this yet, apart from the obvious conclusion that the C# compiler does a much better job than IronPython. Also the size of the IronPython executable is about twice the size of the C# version which I find remarkable as well.

Last remark: since Max already ported this plug-in to Java I finally need to install IKVM so I can compare the results of the three versions. I wonder if there will be more suprises…

Share this:

Like this:

Related

The raw performance difference between IronPython and C# is most likely based on the fact that the C# compiler will generate static code, while IronPython will hate late-bound code and cope with the fact that variables can change type during execution.

Miguel, CPython with Psyco JITed code is faster than IronPython. In fact, its speed is like 1.5 time slower than C#, not 4 times like IronPython.

You cannot blame the dynamicness of the language for a bad implementation. IronPython is crap, deal with it. Dynamic Languages will always be slower, but NOT four times slower. Psyco proved it.
IronPython is a toy made for the conveniance of scripting little crappy tasks for dotnet developers. It’s not made for use in *full* python programs. And the CLR, like the JVM, is not the best place for dynamic languages, like psyco proved.

I don’t know if Parrot and Perl6 will somewhat get out of the “vaporware” status, but if they do, they will replace the JVM and CLR for all important dynamic uses.

@hum: mind you, this 4 times slower is just coming from my micro benchmark. In a real life application this number might be totally different.

It will be interesting to see in the near future how Ruby, Visual Basic, Boo and Nemerle perform on this particular benchmark. However I don’t think the outcome of that tells anything about the usefulness of these languages in general!

I don’t mind people making bold statements on my blog. However I would appreciate it if you could elaborate on why IronPython is just a toy or why the CLR is not suitable for dynamic languages.