OSNews: http://www.osnews.com/story/15302/Microsoft_Ships_Python_on_Net
Exploring the Future of Computingen-usCopyright 2001-2016, David Adamsadam+nospam@osnews.comSat, 10 Dec 2016 03:14:26 GMThttp://www.osnews.com/images/osnews.gifOSNews.comhttp://www.osnews.com
I certainly hope...http://www.osnews.com/thread?146825
http://www.osnews.com/thread?146825This doesn't do for Python what Microsoft's Java implementation did against Java.Thu, 27 Jul 2006 18:25:00 GMTdonotreply@osnews.com (ma_d)CommentsSpeedhttp://www.osnews.com/thread?146826
http://www.osnews.com/thread?146826IronPython 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.Thu, 27 Jul 2006 18:27:00 GMTdonotreply@osnews.com (ma_d)CommentsA bit slow....http://www.osnews.com/thread?146829
http://www.osnews.com/thread?146829I 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.Thu, 27 Jul 2006 18:35:00 GMTdonotreply@osnews.com (snowflake)CommentsRE: I certainly hope...http://www.osnews.com/thread?146863
http://www.osnews.com/thread?146863We can all hope ... but past has proven that it most likely willThu, 27 Jul 2006 20:16:00 GMTdonotreply@osnews.com (Shkaba)CommentsRE: Speedhttp://www.osnews.com/thread?146864
http://www.osnews.com/thread?146864I 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.Thu, 27 Jul 2006 20:25:00 GMTdonotreply@osnews.com (snowbender)CommentsRE[2]: I certainly hope...http://www.osnews.com/thread?146877
http://www.osnews.com/thread?146877Unlike "Microsoft Java", this is free software. You can run it on top of Mono if you'd like.Thu, 27 Jul 2006 21:29:00 GMTdonotreply@osnews.com (thebluesgnr)CommentsRE[2]: Speedhttp://www.osnews.com/thread?146879
http://www.osnews.com/thread?146879Yes, 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).Thu, 27 Jul 2006 21:30:00 GMTdonotreply@osnews.com (ma_d)CommentsRE[3]: I certainly hope...http://www.osnews.com/thread?146882
http://www.osnews.com/thread?146882http://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]Thu, 27 Jul 2006 21:32:00 GMTdonotreply@osnews.com (ma_d)CommentsRE[4]: I certainly hope...http://www.osnews.com/thread?146889
http://www.osnews.com/thread?146889Before 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.Thu, 27 Jul 2006 22:09:00 GMTdonotreply@osnews.com (BrianH)CommentsRE[2]: Speedhttp://www.osnews.com/thread?146959
http://www.osnews.com/thread?146959I 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.Fri, 28 Jul 2006 04:16:00 GMTdonotreply@osnews.com (PlatformAgnostic)CommentsRE: I certainly hope...http://www.osnews.com/thread?147001
http://www.osnews.com/thread?147001Remind 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.Fri, 28 Jul 2006 08:11:00 GMTdonotreply@osnews.com (jmansion)Comments