IronPython URLs

The Loose XAML blog has posted an interesting article profiling some IronPython code and the semantically identical C# and C code (for generating the fibonnaci series). He comes to the unsurprising conclusion that C# is substantially faster, but digs deeper into the results to try and work out why. An interesting discussion ensues in the comments. Performance of IronPython vs. C#  I’ve been using IronPython for a while, and every now and then I do a cursory check to see how it’s performs against the equivalent C# code. C# is generally a touch faster at most logic, but IronPython is faster at dynamic invocation of methods than reflection in C#. In general it’s a wash…over the course of an application you dabble in things that different languages are better optimized to handle. When performance is a wash, you get the freedom to choose entirely based on the features of each language, which is nice. This was going well, until I had a need to do some recursion. I found that the recu...

PyPy is the combination of an interpreter compiler toolchain that allows you to write interpreters (Virtual Machines really) in a static subset of Python, called RPython, along with an implementation of Python in RPython. The compiler toolchain allows you to compile your interpreters for several backends. The major backends are native code, for the JVM and for the CLI (which is .NET and Mono). This allows you to maintain a single codebase and produce an interpreter that runs on all these platforms. The PyPy .NET backend is called pypy-cli. PyPy on its own runs at somewhere between the same speed as CPython and twice as slow. Because it has better garbage collection (PyPy doesn't use reference counting) there are some things it does faster but there are also places it is slower. There are various cool things about PyPy, for example it is already useful where you want a sandboxed Python interpreter. The really cool thing, and perhaps one of the driving forces for creating PyPy...

Another collection of blog entries and articles related to IronPython and the Dynamic Language Runtime. Win a book on IronPython or F# Allan Juhl Petersen has a competition running until 29th September where you can win a book on IronPython (and a good book it is too ) or F#: I have created 7 questions, in different programming languages such as C#, F#, Ironpython, C++, Java and of course the well known and liked true or false . The questions are designed to give a number of points, where the maximum number of points given can be read in the text of the assignment. The rules are simple, the one with the highest score on points, will win. Points will be given for correctness and effort. An assignment might give 6 point, but if not entirely correct, it will be given some points for effort. The winner gets Office 2007 Student version and gets to choose between two books ? Foundations of F# or IronPython in Action - and the runner-up gets the one that the winner did not choose. Compa...

Another collection of blog entries and articles related to IronPython and the Dynamic Language Runtime. Scripting (IronPython) exposing Naro document API IronPython was integrated for some time to NaroCAD . But in fact it has two problems: It was not able to access NaroCAD shapes or anything from NaroCAD so it was not powerful enough to do something useful, excluding you did want to make a processing task using python IronPython implementation (and python in itself) do not work with Generics. So even you had access to Naro's document model, the Naro's extensible model was not accessible to IronPython script programmers. This is why it was used lazy loading of IronPython as it does useless slowdown on startup of NaroCAD. Right now both are addressed, exposing to you a document reference that you can create from it using a PyNodeUtil class a shape node. This is fairly important achievement as it can make easier without recompile NaroCAD to migrate your shapes if you can expose t...

Another collection of blog entries and projects related to IronPython and the Dynamic Language Runtime. IronRuby 0.9 starts 6 times faster than IronPython 2.6B1, why is that? Does anyone know? IronPython 2.0 is significantly slower to start than CPython, which is an issue for those writing command line tools and full applications in IronPython. IronPython 2.6 improves the situation, but as the lament in this short blog entry expresses it is still slow even when compared to IronRuby: IronRuby 0.9 starts 6 times faster than IronPython 2.6B1 Why is that? Don’t they use the same DLR engine? If IronPython started the same way, probably I would not use ‘CPython plus .Net exposed through MSFT Com’ technique. It is just unfair. On the usual support channel ( Twitter ) Dino Viehland explained that the IronPython interpreter does a bunch of work at startup time that IronRuby doesn't. On startup the interpreter imports the site module site just like CPython (and IronPython uses site.py from ...

Everyone loves benchmarks, even though they are usually misleading at best. Of course I'm no exception. Here are three snippets of news on IronPython performance that have surfaced over the last week or so. IronPython 2.0.1 and 2.6 Beta 1 compared to CPython and Jython ( posted to Twitpic by felipez ) on Mono revision 136556: Using the pystones benchmark IronPython on Mono clocks in faster than CPython or Jython. Nice. One particular bugbear of IronPython performance has been startup time. On 64bit Windows the startup time goes from being merely bad to positively ridiculous. This is because the .NET 64bit JIT is slow to do its job and IronPython generates a lot of code needing to be JITed at startup. A lot of work has gone into IronPython 2.6 to improve startup time (by reducing the amount of rule generation done on startup), and this blog entry Dave Fugate explains something they have done specifically to address startup perf on 64bit Windows - and shows off the results: IronPytho...

Robert Smallshire has been working on an implementation of BBC Basic written in IronPython . During development he has been disappointed with the performance of IronPython, in fact he discovered that some of his code was running massively slower than the same code on either CPython (the native implementation of Python) or Jython (the implementation for the Java Virtual Machine). He posted a series of blog entries on this where he dug deeper into the problem and eventually, with the help of the IronPython team he found a solution. I've listed the blog entries in the order they were posted; what follows is a story of performance, impressive charts and an explanation: Dismal Performance with IronPython Significant claims have been made about the performance of IronPython, notably back at its inception in 2004 when Jim Hugunin, creator of both IronPython and its cousin Jython, presented a paper on IronPython performance at PyCon. Since then, there have been numerous claims to IronPytho...

An interesting article by James Gardner comparing the performance of IronPython, Jython, Scala and CPython for serving web pages. Not only does it carry the usual caveats of all benchmarking and performance comparisons, but the version of IronPython used is the very old IronPython 2.0 Alpha 5 which still comes with Mono. UPDATE: it turns out that not only is the article using an old version of IronPython, but it advises installing Mono 1.9.1 because of the handy universal installer for Linux. Whilst this is indeed handy it is also outdated (the installer used to be built with a tool called BitRock which is non-free). The latest version of Mono is 2.4. That aside it is still an interesting read and includes instructions on how to get Mono installed and have IronPython working with the Python standard library on Linux: IronPython, Jython, Scala and Python: A Fairly Meaningless Server Performance Comparison IronPython 2.0 is a full implementation of Python 2.5 targetting the .NET platform...

Benjamin Nitschke's has written a couple of posts on writing your own programming language with the Dynamic Language Runtime. The first is a long list of links and resources on the DLR and the tools (like the ANTLR parser) used in creating a programming language. The second is a very long entry comparing the performance of code written in various ways - including on top of the DLR. Writing your own programming language with the DLR I will also try to post some useful links about my recent DLR (Dynamic Language Runtime for .NET) research. I have been working a bit on the DLR before, mostly together with Silverlight, which was cool, but Silverlight was way too hard to work with and I still think it is not distributed enough. And even before that quite a bit with the Visual Studio SDK, early IronPython versions and other language implementations in .NET and even with native c code (but usually I just modified existing samples). I have also modified Lua for my own needs recently and m...

Dave Fugate is an IronPython tester, and often responsible for releases. He's posted a few blog entries on recent changes in IronPython 2.6 (alpha 1 was just released ) and building IronPython from source for Silverlight. CPython 2.6 Standard Library and IronPython 2.6 In Python 2.6 the standard library collections module uses sys._getframe , which doesn't work for frame depths greater than 0 in the current IronPython. A whole host of other standard library modules depend on collections, meaning that they are all currently broken for IronPython 2.6! Dave explains how to modify collections.py to get round the problem. The good news is that in the final version of IronPython 2.6 getframe will be available from a command line switch (there is a performance hit for having it enabled). Without the switch it will be undefined (and collections.py already has a workaround for this), so that in either case you will be able to use an unmodified standard library. Building IronPython / Ir...

A selection of IronPython and Dynamic Language Runtime related web pages and blog entries. Getting Started with IronPython John Cook makes a start with IronPython. This means using one of the three distributions available from the Codeplex homepage: the source code, the prebuilt binaries or the msi installer. IronPython is a One Way Gate Having got started John Cook is disappointed that he can't use Python C extensions from IronPython, and finds it hard to call into IronPython from C#. The answer to the latter problem is to use the IronPython hosting API , and John Cook has written another blog post on the former problem which will get an IronPython-URLs entry all of its own. NaroCAD to have support for IronPython 2.0! This seems like an exciting announcement, but is short on links to find further information. The upshot is that NaroCAD has, or will shortly have, support for scripting it with IronPython 2 and possible IronRuby as well: This means that with minimal change right now...

Philipp Sumi has been looking at performance optimizations when using IronPython hosted from C#. Reusing Import Symbols to Avoid Performance Hits Lets do an artificial sample: The snippet below just increments a variable by one. As expected, it executes blazingly fast - after compilation, it executes a few thousand times without getting over a single millisecond: value = value + 1 Now look at the following example: import clr clr.AddReference('System.Xml') from System.Xml import * value = value + 1 Basically, this snippet performs the same logic (incrementing the ‘value’ variable), but it contains an import for the System.Xml namespace. It’s not necessary, but it still needs to be compiled. Executing this (compiled!) script 4000 times takes over 5 seconds! From a hosting point of view, the extra time is spent populating the namespace (the ScriptScope ) in which the code is executed. Philipp shows how to reuse imports by creating new scopes from a pre-populated SymbolDictionary...

In the latest release of Resolver One we improved startup time by about 20-30%. Most of the startup time in Resolver One is spent in importing Python modules, which is considerably more expensive in IronPython 1 than it is in CPython (even when compiled in binary form). We achieved most of our speedup by delaying the creation of certain objects until they are needed (if ever), and other standard techniques for performance improvement. There is good news for IronPython 2. Binary compilation is much more efficient as we can compile multiple packages into a single binary and then ngen (pre-JIT), making imports faster. Whilst exploring how to improve our startup time Kamil Dworakowski experimented with a system for performing parallel imports on multiple threads. Kamil's Parallel Import Project for IronPython IronPython doesn't have the same import lock as CPython, so you need to ensure that parallel imports don't pull in the same modules simultaneously or some of the impo...

Dave Fugate has written part 3 of his guide to measuring IronPython performance. In this entry he discusses things that can affect performance - not just different versions of .NET, but even security patches (!) can make a difference. Measuring IronPython Performance Part III Interestingly, due to practical limitations, the dynamic languages team only test on various configurations of Vista. This is despite the fact that, however much Microsoft wishes otherwise, most of their customers are still going to be using it with Windows XP... Vista comes with .NET 3 as standard - but IronPython itself only depends on .NET 2 (with Visual Studio 2008 you can set the version of .NET you are targeting when you compile). Specifically, IronPython 2 depends on .NET 2 SP1,which is actually more recent than .NET 3 - Service Pack 1 came out in November 2007. At Resolver Systems we are selling Resolver One into financial organisations, some of whom are technologically conservative, so it is possible tha...

Python is now in a very healthy position, with several major implementations: CPython, Jython, IronPython and PyPy. Python itself is very loosely specified (can anyone point me to the documentation for the __reversed__ method for example?). The specification is partly in the documentation and partly in CPython, which is called the 'reference implementation'. This blog entry is about the different implementations of Python, which parts of Python are specification and which are implementation details and what it means to talk about the performance of Python in the light of the different implementations. Django on Jython, Python Implementations and Performance UPDATE: It turns out that documentation for __reversed__ was added to the Python 2.6 docs in January. However it (currently) incorrectly states that it is new in 2.6 when it was in fact new in Python 2.4.

Dave Fugate is a tester on the IronPython team. The IronPython team has recently done some great work on IronPython 2 performance improvements and Dave has started blogging on how they measure IronPython performance. His initial blog entry introduces himself and what he does (plus IronPython related topics he intends to blog about): Jumping back on the blogging bandwagon He has a two part blog entry on how they measure performance (the hardware infrastructure) and the results over time comparing 32bit to 64bit OSes. Every checkin triggers a benchmark run that takes over six hours (running a combination of PyBench, PyStone and custom microbenchmarks) on custom OS install. Measuring IronPython Performance Part 1 The second part compares performance (both PyStone and PyBench) for two identical machines - one running 32bit Vista and the other running 64bit Vista. Interestingly performance is worse for x64 architecture than it is for x86. Measuring IronPython Performance Part 2

After the debate on comp.lang.python about Python vs IronPython performance , 'sokoide' has posted a mini-benchmark comparing Python and IronPython (but heed Steve Holden's wise words on benchmarks in the newsgroup thread). It appears to benchmark an implementation of the N-Queens puzzle (although I don't think he has posted the code used). In this benchmark IronPython comes out as a clear winner. Python Mini Benchmark Interestingly Python on Windows appears to do better than Python on Mac OS X. In the past this has been attributed to Visual Studio (the Windows compiler) being optimised for performance where gcc is optimised for portability.

Paolo describes the latest optimisations he has made in the Mono JIT compiler - and how this leads to memory savings for IronPython: Memory Savings with Magic Trampolines in Mono

'Someone' (couldn't find a name - sorry) posts a blog entry arguing that the implementation strategy for IronPython on Tamarin (IronMonkey) must be slow: How Badly Will IronMonkey Hurt Performance? Unsurprisingly, I'm not convinced: My Response In a further non-surprise, the original poster is not convinced by my response: Perspective on Python Performance

In the DLR Talk at Mix '07 , Jim Hugunin claimed a 12% improvement in performance between IronPython 2 and IronPython 1. Seo Sangyheon ran some tests, and discovered that IronPython 2 is either faster or slower; depending on what platform it runs on ... IronPython 2 compared to IronPython 1: Mono 1.2.4+: -32% Whidbey: -21% WinFX: +6% MIX07 (Orcas?): +12% This shows that IronPython 2 makes heavy use of some of the improvements in recent versions of the CLR runtime.