IronPython 2.6alpha 1 Released
Dave Fugate has just announced the release of IronPython 2.6 alpha 1.
There is also a page comparing performance of the IronPython release with Python 2.6.1. The performance shows a degradation because the new adaptive compilation techniques are very much a work in progress:
The announcement:
We’re pleased to announce the release of IronPython 2.6 Alpha 1. As you might imagine, this release is all about supporting new CPython 2.6 features such as the ‘bytes’ and ‘bytearray’ types (PEP 3112), decorators for classes (PEP 3129), advanced string formatting (PEP 3101), etc. The minimum .NET version required for this release is the same as IronPython 2.0; namely .NET 2.0 Service Pack 1. Unlike the 2.0 series of IronPython, we plan to release only a couple Alphas and Betas of IronPython 2.6. As such, it’s key that we get your feedback on the release(s) quickly to incorporate requested changes.
Besides CPython 2.6 features, another significant change in this release is that ipy.exe now uses “adaptive compilation” by default. Adaptive compilation is a technique in which IronPython:
1. Interprets and executes Python method calls up to N times for a given method. If you’re only going to execute a method a few times, it’s typically faster to interpret the method instead of compiling and executing it
2. Compiles and executes the Python method call on the N+1 invocation of the method. Compilation of a Python method is a heavyweight operation, but we can reuse the result for subsequent invocations
3. Reuses the previously compiled method for new calls to the Python method. This operation is much faster than interpreting the method call as the method was already compiled in the previous step
The reason for this change is that it provides a nice performance gain for Python code containing lots of functions/methods that only get called a few times. All this said, this feature is still undergoing active development and as a consequence some Python scripts may actually run slower with it turned on. For this reason, our old default mode of running Python scripts is still available by passing the –O or -D flags to ipy.exe. Any feedback on how this new feature affects your IronPython applications performance-wise would be greatly appreciated.
There’s also a few minor changes since IronPython 2.0.1 that are worth calling out here:
The IronPython Team
There is also a page comparing performance of the IronPython release with Python 2.6.1. The performance shows a degradation because the new adaptive compilation techniques are very much a work in progress:
The announcement:
We’re pleased to announce the release of IronPython 2.6 Alpha 1. As you might imagine, this release is all about supporting new CPython 2.6 features such as the ‘bytes’ and ‘bytearray’ types (PEP 3112), decorators for classes (PEP 3129), advanced string formatting (PEP 3101), etc. The minimum .NET version required for this release is the same as IronPython 2.0; namely .NET 2.0 Service Pack 1. Unlike the 2.0 series of IronPython, we plan to release only a couple Alphas and Betas of IronPython 2.6. As such, it’s key that we get your feedback on the release(s) quickly to incorporate requested changes.
Besides CPython 2.6 features, another significant change in this release is that ipy.exe now uses “adaptive compilation” by default. Adaptive compilation is a technique in which IronPython:
1. Interprets and executes Python method calls up to N times for a given method. If you’re only going to execute a method a few times, it’s typically faster to interpret the method instead of compiling and executing it
2. Compiles and executes the Python method call on the N+1 invocation of the method. Compilation of a Python method is a heavyweight operation, but we can reuse the result for subsequent invocations
3. Reuses the previously compiled method for new calls to the Python method. This operation is much faster than interpreting the method call as the method was already compiled in the previous step
The reason for this change is that it provides a nice performance gain for Python code containing lots of functions/methods that only get called a few times. All this said, this feature is still undergoing active development and as a consequence some Python scripts may actually run slower with it turned on. For this reason, our old default mode of running Python scripts is still available by passing the –O or -D flags to ipy.exe. Any feedback on how this new feature affects your IronPython applications performance-wise would be greatly appreciated.
There’s also a few minor changes since IronPython 2.0.1 that are worth calling out here:
- IronPython.msi now installs NGEN’ed binaries by default
- IronPython.msi now offers a little more selection with respect to what you’d like to install. For example, Silverlight templates are optional
- The default installation location of IronPython.msi no longer indicates whether the 2.6 release is an Alpha, Beta, or a patched release. Future IronPython 2.6 installations will replace previous 2.6 releases which will be uninstalled automatically
- The -X:PreferComInteropAssembly flag has been removed. All COM interop is now done through normal COM dispatch
The IronPython Team
"
ReplyDeleteThe reason for this change is that it provides a nice performance gain for Python code containing lots of functions/methods that only get called a few times.
"
???
Shouldn't it speed up programs that call functions multiple times, or is this a comprehension test for the reader :-)
- paddy.
If it's a comprehension test, you fail. ;-)
ReplyDeleteThat particular feature speeds up the execution of "functions / methods that only get called a few times".
How can that be Michael.
ReplyDeleteThe quote seems to apply to the three points about Adaptive compilation.
My intuition has been known to fail, but wouldn't AC speed up functions called multiple times, and so slow down programs in which all functions are NOT called multiple times?
Either way, I'm a Python fan - not a language lawyer so go right ahead :-)
- Paddy.
P.S. Keep up the excellent work selling IronPython to the masses.
Hi Paddy,
ReplyDeleteCompilation takes time. The point of adaptive compilation is that if we are only executing the code a few times then the time taken to compile is likely to outweigh the performance cost of just interpreting the code.
So adaptive compilation allows a method to be interpreted the first couple of times and then compiled in the background if it is used a lot.
If you precompile code (like we do at Resolver Systems) then adpative compilation isn't relevant.
This is all my understanding anyway...
Michael
Thanks for the explanation. In my application I do not notice any difference anyway, but I do the performance critical stuff in C# anyway now (not because I have to, it is just code I had before).
ReplyDelete