Submitted by Microsoft has shipped the release candidate for IronPython 1.0 on its CodePlex community source site. IronPython is a project that implements the dynamic object-oriented Python language on top of the Microsoft Common Language Infrastructure. IronPython is both well-integrated with the .Net Framework and is a true implementation of the Python language.
This doesn’t do for Python what Microsoft’s Java implementation did against Java.
We can all hope … but past has proven that it most likely will
Unlike “Microsoft Java”, this is free software. You can run it on top of Mono if you’d like.
http://www.fsf.org/licensing/licenses/index_html#NonFreeSoftwareLic…
[QUOTE]
Microsoft’s Shared Source CLI, C#, And Jscript License
This license does not permit commercial distribution, and only allows commercial use under certain circumstances.
Microsoft has other licenses which it describes as “Shared Source”, some of which have different restrictions.
[/QUOTE]
Before you pull out the FSF criticism, you should know that the license they are referring to is not the license for IronPython. Here is the license for IronPython: http://www.codeplex.com/Project/License.aspx?ProjectName=IronPython
In summary, commercial and non-comercial use is OK, there is a warranty disclaimer and limitation of liability that you must pass on (but no cover-their-legal-bills clause), and there is a don’t sue anyone over patents related to this software or you’ll lose the license clause.
Basically BSD plus patent handling. Good license overall.
Remind me what that was? At the time I was entirely in favour of the COM compatible extensions, and regarded Sun’s stance critically. I still do. Having
a garbage collected ‘safe’ language with which to write COM components would have been a boon – and it would have enabled me to start migrating core functions from Win32-specific C to portable Java and then deploy it elsewhere, which would have accelerated my Java use. Sun’s suggestion that I need to be saved from writing Windows-specific code and would be unable to determine which bits of my system could be portable and which specific is and was insulting.
IronPython also leverages the CLI to achieve good performance, running up to 1.5 times faster than the standard C-based Python implementation on the standard Pystone benchmark.
Honestly I expected to see more of a speed gain, I guess CPython is more efficient than I’d thought it was.
I too initially expected more of a speed gain, but only because I thought that by default, Python used a simple interpreter (an abstract syntax tree interpreter just like Ruby), but CPython, the standard Python implementation has a bytecode compiler and a bytecode interpreter, which is already faster. So, we are comparing running Python on a virtual machine with accompanying instruction set specifically designed to run Python code with a virtual machine which was more or less designed from the ground up to support several different languages. So, I think that a 1.5 speedup factor is not that bad.
I do wonder whether the JIT is activated/works and how much of a difference the JIT can make in the Pystone benchmark (I don’t know the benchmark). I imagine that with dynamic languages like Python, and also Ruby, a JIT can’t improve performance much in a benchmark which mainly consists of method calls and not of pure computations.
Also something to take into account is that CPython uses reference counting (with a fallback on a real garbage collector for cycles), which increases the cost of creating/removing references, while the CLR uses mark-compact garbage collection (which will most likely be cheaper overall). So, I think part of the speedup also comes from this, but that also depends on the characteristics of the benchmark.
Yes, a computation benchmark would be great. I know from experience that Python does nothing to optimize complex computations, or nothing very useful, compared with languages like Java (the Sun implementation).
I don’t think .NET has an interpreter at all. All code that is executed is JITTed beforehand. The speed gain is probably from the fact that IronPython is running native code once the methods are jitted and CPython is interpreting bytecode. Dynamic method invocation used to be really slow in .NET and the code could not be thrown away when the method was no longer needed. In the CLR 2.0, there is a DynamicMethod class which can be GCed just like any other class when references to it go away.
Another reason IP is faster is likely the more efficient implementation of Python datastructures within the .NET class library. A lot more time and money probably went into optimizing everything in .NET than in CPython.
I agree, I was a bit disappointed in the speed up, only 1.5, I was expecting more. Ive translated some nontrivial C programs into C# and seen the C# apps run at about 70% of the C versions, its a rough estimate admitedly but not too bad so I was expecting python to deliver more, presumably dynamic language invokation is slow.