🔒 Locked

IronPython: .NET is a good platform for dynamic languages

Started by Arild Fines Mar 31, 2004 at 6:35 PM 5 replies 2.9k views

Original Post

Mar 31, 2004 at 6:35 PM

Initial attempts[1] by Mark Hammond(who was working for ActiveState at the time) to create a Python implementation for the .NET platform didn''t prove to be very successful. His conclusion was that

"The speed of the current system is so low as to render the current implementation useless for anything beyond demonstration purposes."

Since that time, .NET has gotten a reputation[2] for being a bad target for dynamic languages. Jim Hugunin, the author of, among other things, JPython and NumPy, delivered a paper at PYCON 2004 on his Python implementation for the .NET platform, called IronPython. The PyStone benchmarks shows that IronPython is on average 1.4 times faster than CPython. Obviously, it was slower than CPython at some things; the "eval" function in particular(which is also pretty slow in JPython). The feature list is impressive:

Fast - IronPython-0.2 is 1.4x faster than Python-2.3 on the standard pystone benchmark. More details about performance are contained in this paper for PyCon 2004.
Integrated with the Common Language Runtime - IronPython code can easily use CLR libraries and Python classes can extend CLR classes.
Fully dynamic - IronPython supports an interactive interpreter and transparent on-the-fly compilation of source files just like standard Python.
Optionally static - IronPython also supports static compilation of Python code to produce static executables (.exe''s) that can be run directly or static libraries (.dll''s) that can be called from other CLR languages including C#, VB, managed C++ and many more.
Managed and verifiable - IronPython generates verifiable assemblies with no dependencies on native libraries that can run in environments which require verifiable managed code.

Hugunin''s conclusion:

"IronPython can run fast on .NET and presumably on any decent implementation of the CLR. Python is an extremely dynamic language and this offers compelling evidence that other dynamic languages should be able to run well on this platform. However, implementing a dynamic language for the CLR is not a simple process. The CLR is primarily designed to support statically typed OO and procedural languages. Allowing a dynamic language to run well on this platform requires careful performance tuning and judicious use of the underlying CLR constructs."

Unfortunately, there doesn''t seem to be any code or information available beyond the IronPython[3] site and the transcript[4] of the PYCON talk. But I for one am looking forward to playing with this as soon as an implementation is available. How about you? [1] http://www.activestate.com/Corporate/Initiatives/NET/Research.html [2] http://www.infoworld.com/article/03/08/22/33OPstrategic_1.html [3] http://ironpython.com [4] http://www.python.org/pycon/dc2004/papers/9/IronPython_PyCon2004.html -- AnkhSVN - A Visual Studio .NET Addin for the Subversion version control system. [Project site] [Blog] [RSS] [Browse the source] [IRC channel]

ggs

Mar 31, 2004 at 8:07 PM

This isnt suprising.

Getting Python to run efficiently on a JVM means that you can efficiently run it under .NET.

If for no other reason you can implement a JVM in .NET which compiles Java bytecode to CLI(via IKJVM) and have the java code have full interoperivity with existing .NET classes.

So the lack of an efficient dynamic language on the .NET framework is purely the result of laziness and/or spite on the implementers part. If it can run under a JVM, it can run under .NET.

Also IronPython under v2.0 of the .NET framework will have significant preformance enhancments for several areas.

Function calls when implemented via delegates will achieve a massive increase in their performance(roughly x50 faster!).

Generics biult into the CLI should also provide significant performance increases, because the concrete versions can be dynamically created at runtime.

[edited by - ggs on March 31, 2004 9:27:30 PM]

Kylotan

Mar 31, 2004 at 8:37 PM

quote:
Original post by Arild Fines
The PyStone benchmarks shows that IronPython is on average 1.4 times faster than CPython. Obviously, it was slower than CPython at some things; the "eval" function in particular(which is also pretty slow in JPython).

I''d be interested to see how much of that performance benefit comes from the CLR and how much merely comes from a different approach to the implementation. Perhaps much of that speed increase could be added into the core of Python?

I''m a bit unsure as to why this would have a future though, unless the performance gain can be shown to be consistent.

[ MSVC Fixes | STL Docs | SDL | Game AI | Sockets | C++ Faq Lite | Boost
Asking Questions | Organising code files | My stuff | Tiny XML | STLPort]

Fruny

Mar 31, 2004 at 8:47 PM

But I for one am looking forward to playing with this as soon as an implementation is available.

During his talk, the author informed us that this was still a research prototype and that no release was planned yet. He pointed out that one of the optimisation he did was to generate code for common cases of function calls (method, function, # of argument), a point that Guido duly noted down, saying that they would probably do the same with CPython.

The Starkiller talk was great too.

The benchmarks did show that you may have to select one platform or another depending on the nature of your application. The truly dynamic features (eval) are much slower because of the overhead of running the IL generator (of course he did point out that if you have a lot of evals you are probably doing something wrong).

Of course choice is a good thing

It would have been interesting to see him benchmark against Python 2.3 or 2.4a0 (Raymond Hettinger is adding new opcodes to python to get better performance for some language features, something you can't easily do with the CLR, unfortunately). [edit: The benchmark already uses python 2.3 as baseline, silly me]

I've not taken notes during the talks but I may remember a few things if given adequate prompting.

[edited by - Fruny on March 31, 2004 9:54:33 PM]

Fruny

Mar 31, 2004 at 8:52 PM

quote:
Original post by Kylotan
I''d be interested to see how much of that performance benefit comes from the CLR and how much merely comes from a different approach to the implementation. Perhaps much of that speed increase could be added into the core of Python?

It varies from feature to feature. Python is faster with memory operations because is does have a number of specialized allocators, whereas the CLR need to cover the general case.

Further work on the CLR itself is expected to yield some further gain but, as I mentioned in my previous post, ideas are propagating back into CPython.

Flarelocke

Mar 31, 2004 at 10:50 PM

quote:
He pointed out that one of the optimisation he did was to generate code for common cases of function calls (method, function, # of argument), a point that Guido duly noted down, saying that they would probably do the same with CPython.

This sounds much like Psyco.

Grugnorr

Mar 31, 2004 at 11:26 PM

Cool :D, I´ve been wanting to use Python with my C# code since I left C++

What the hells!

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.