From DOTNET-LANGUAGE-DEVS@DISCUSS.MICROSOFT.COM Mon Dec 8 20:16:21 2003 Return-Path: Delivered-To: miguel@ximian.com Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by skeptopotamus.ximian.com (Postfix) with ESMTP id C10CD630B0; Mon, 8 Dec 2003 20:16:21 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00C6C5E8@cherry.ease.lsoft.com>; Mon, 8 Dec 2003 20:16:21 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 1247884 for DOTNET-LANGUAGE-DEVS@DISCUSS.MICROSOFT.COM; Mon, 8 Dec 2003 20:16:20 -0500 Received: from 64.164.98.52 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 8 Dec 2003 20:16:20 -0500 Received: from JimHugunin (adsl-63-195-57-227.dsl.snfc21.pacbell.net [63.195.57.227]) by mtaw4.prodigy.net (8.12.10/8.12.10) with ESMTP id hB91GGCC026582 for ; Mon, 8 Dec 2003 17:16:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcO98gqXYgRQKihlSrWze4fWDVBRGg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: <200312090116.hB91GGCC026582@mtaw4.prodigy.net> Date: Mon, 8 Dec 2003 17:16:15 -0800 Reply-To: "Compiler Developers for .NET" Sender: "Compiler Developers for .NET" From: Jim Hugunin Subject: Python can run fast on the CLR To: DOTNET-LANGUAGE-DEVS@DISCUSS.MICROSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on skeptopotamus.ximian.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,MISSING_OUTLOOK_NAME autolearn=no version=2.60 X-Spam-Level: X-Evolution-Source: mbox:/var/spool/mail/miguel Content-Transfer-Encoding: 8bit I've been working off and on for the past couple of months on a new implementation of Python for the CLR called IronPython. It compiles Python programs into verifiable IL and then dynamically executes them. This project began as an investigation of the performance issues involved with compiling Python to run as managed code on the CLR. Previous work had indicated that runtime performance could be prohibitively slow [1]. The early results with IronPython show that Python compiled to IL can run fast. On the standard pystone benchmark, IronPython-0.1 is 70% faster than CPython-2.3. The numbers for pystone as well as several micro-benchmarks are shown below. For ease of comparison, all times are normalized to Python-2.3. Smaller numbers indicate faster performance. IronPython-0.1 Python-2.3 Python-2.1 Jython-2.1 pystone 0.58 1.00 1.29 1.61 function call 0.19 1.00 1.12 1.33 integer add 0.59 1.00 1.18 1.08 string.replace 0.92 1.00 1.00 1.40 range(bigint) 5.57 1.00 1.09 16.02 eval("2+2") 66.97 1.00 1.58 91.33 These numbers show some constructs that perform very well on the CLR and others that perform poorly. It's unsurprising that the two areas of worst performance are the same for both IronPython and Jython. The range benchmark creates an array filled with hundreds of thousands of newly created very small objects (4-bytes of data each). These need to be objects instead of structs because they need methods with dynamic dispatch. The eval benchmark is primarily measuring the time to dynamically load very small chunks of code. There are a few points to note about the comparison with Jython's performance. First, IronPython-0.1 is still a rough prototype while Jython-2.1 is a full implementation of the Python platform used in many commercial projects. Recently, correctness and completeness have been the primary drivers of Jython's development. On the other hand, Jython is one of the highest performing scripting languages for Java [2], and thus the performance comparison bodes very well for other scripting languages on the CLR. The current version of IronPython doesn't use any type inference or partial evaluation to improve performance. These advanced techniques hold the promise of dramatic improvements to both the performance [3] and the static checking (without static typing) of Python code. I'm particularly excited by the prospect of combining these techniques with the new dynamic code modification capabilities in the 1.2 CLR. Before I can get to these further optimizations, I need to spend several more weeks focusing on correctness and completeness instead of performance. This will let me pass enough of the python regression test suite to start working with larger and more interesting programs. FYI - Tomorrow I'm starting a consulting project that will consume all of my time through the end of January. I wanted to report these early results somewhere before that begins. After January I hope to have the time to continue this work. Jim Hugunin - http://hugunin.net ----------------------------------------------------- References: [1] Mark Hammond, Python for .Net: Lessons Learned, ActiveState Corp., November 2000. (http://www.activestate.com/Corporate/Initiatives/NET/Research.html) [2] David Kearns, Java scripting languages: Which is right for you?, JavaWorld, April 2002. (http://www.javaworld.com/javaworld/jw-04-2002/jw-0405-scripts.html) [3] Jim Hugunin, JPython Update, 7th International Python Conference, Houston, Texas, November 1998. (http://www.jython.org/jpython-talk-1.ppt)