 Hugunin's IronPython
started 12/12/2003; 7:22:56 PM - last post 12/15/2003; 1:50:04 PM
|
|
Patrick Logan - Hugunin's IronPython 
12/12/2003; 7:22:56 PM (reads: 10972, responses: 4)
|
|
| Hugunin's IronPython |
|
Jim Hugunin has a new project, named IronPython, which is an implementation of Python for the Microsoft Common Language Runtime environment. The remarkable thing is that IronPython runs faster than the Python implementation in C according to the pystone benchmark. (See Hugunin's original message for full details.)
Miguel de Icaza, lead developer of the Mono framework, also comments on Hugunin's remark with delight and says that this might "stop the meme of '.NET is slow for scripting languages'".
I don't think it should be a surprise that Python compiled to CIL and then translated to native instructions is faster than CPython interpreted byte code.
What's unclear to me so far is how much time is taken to compile IronPython in the first place. That is, is IronPython an interactive environment or a compile ahead environment?
I think Sharp Smalltalk already demonstrates that compile ahead works well. I am betting IronPython operates similarly. To my knowledge, no one has implemented an interactive environment yet for a dynamic language that is compiled to CIL.
Posted to Python by Patrick Logan on 12/12/03; 7:26:03 PM
|
|
|
|
Samuele Pedroni - Re: Hugunin's IronPython
12/13/2003; 12:58:33 AM (reads: 857, responses: 0)
|
|
|
There are numbers for eval, and I don't think it is using a double strategy of static compilation plus an AST/bytecode interpreter for runtime evaluation (like JScript.NET, at least 1.0, did). In fact the original message contains:
" The eval benchmark is primarily measuring the time to dynamically load very small chunks of code. "
http://primates.ximian.com/~miguel/ironpython
What is true is that so far .NET did not support unloading through GC of dynamically loaded types and code. The unloading granularity was an entire AppDomain upon explicit request.
See the comments here
http://blogs.gotdotnet.com/cbrumme/PermaLink.aspx/56dd7611-a199-4a1f-adae-6fac4019f11b
I don't know whether such a feature is finally planned (?).
|
|
Chris Double - Re: Hugunin's IronPython
12/13/2003; 4:16:48 PM (reads: 757, responses: 0)
|
|
|
S# (previously known as SmallScript) has an interactive environment which compiles to CIL and it is a dynamic language. Their site (www.smallscript.com) seems to be down at the moment though.
|
|
Patrick Logan - Re: Hugunin's IronPython
12/14/2003; 6:08:27 PM (reads: 660, responses: 0)
|
|
|
S# has an interactive environment... Their site (www.smallscript.com) seems to be down at the moment though.
I think there is one person working somewhat less than full-time on S#. This was supposed to be the first dynamic language for dotnet, pave the way for others to follow, etc. The product has been slow to market and the site is not often updated. I would not hold out much hooe for S#.
Microsoft lowered their priority on dynamic languages before the first release. Peter Drayton and others have indicated there is some more attention being paid for the next release, I think, so we can hold out some hope for the future.
Meanwhile Haskell, Python, VisualWorks Smalltalk, PLT Scheme, et al. have shown that the most viable integration is via foreign function calls, just like the old days.
|
|
Dan - Re: Hugunin's IronPython
12/15/2003; 1:50:04 PM (reads: 484, responses: 0)
|
|
|
Beating CPython at the pystone benchmark's not tough, as I was told back when I was considering it for the pie-thon test program--speeding it up by a factor of 10 or 20's not difficult, as the benchmark tests the raw op dispatch loop more than anything else. What'd be more interesting would be testing method dispatch and attribute twidding, which is where things'll slow down rather a lot. (As you have to interject yourself in the method dispatch, since Python allows you to change and remove methods at runtime, which .NET does not allow, so you can't unconditionally use .NET's method dispatch code)
|
|
|
|