[IronPython] IronPython compilation with mono

[Paolo Molaro]

On 03/29/05 Jim Hugunin wrote:
> Cool.  It sounds like it would be a nice thing if we shipped a simple
> makefile in the top IronPython directory for people who don't have

Yep.

> else pointed out, ipython is already in use.  'ironpy' is the most
> appealing of your list of options.  Does anyone have a better
> suggestion?

ironpy gets my vote, too. I don't like FePy myself: there is no py chemical
element. You could spell it FePY, but, first, I don't like multi-case
words for commands (especially command line unix ones) and second
FePY doesn't exist as a molecule:-)

> Do you have a problem with the .exe at the end of the name or just the
> length of IronPythonConsole?

The .exe is not an issue. Any sane distributor will ship a shell script
with basically "mono ironpy.exe" in it and name it without the .exe.

> The packaging is a good suggestion as well.  The tools that I use now to
> extract zip files will be default put the files in a directory with the
> name of the zip file, so the current design works fine on my box.  I

Now, this begs the question: where the tools hacked to do that because
too many windows people would not create a proper archive with all the files
in a directory or the other way around? :-)

> realize that isn't universal.  One dilemma with extracting into a
> versioned directory is how often to change the name.  Do you think the
> 0.7.1 should go into the same directory as 0.7 or not?

The accepted way to do it is to name the directory as:
	project-version
Since 0.7.1 is a different version the directory would be different as well.

> I'm glad to hear 0.7 is a little faster than 0.6 for you.  I'd be
> curious to see numbers comparing mono 1.0 and 1.1 if you had them.

Sure (using mono from svn, so about the same as 1.1.5 and an older mono
close to 1.0.5):
pystones/second:
	34950	mono 1.0.x
	35971	python 2.3
	40322	python 2.4
	49121	mono 1.1.x
So it's a 40% improvement in this case when going from mono 1.0 to 1.1.x.
The pie-thon bench gives some more interesting results:

mono 1.0
b0 = 3.92477035522461 -- [4.13869476318359, 3.71084594726563]
b1 = 0.596031188964844 -- [0.700836181640625, 0.491226196289063]
b2 = 0.375785827636719 -- [0.369209289550781, 0.382362365722656]
b3 = 1.314697265625 -- [1.31097412109375, 1.31842041015625]
b4 = 1.41418838500977 -- [1.41653442382813, 1.41184234619141]
b5 = 86.0883674621582 -- [86.6897125244141, 85.4870223999024]
b6 = 2.75988006591797 -- [2.76504516601563, 2.75471496582031]

mono svn
b0 = 2.2257194519043 -- [2.46144104003906, 1.98999786376953]
b1 = 0.433116912841797 -- [0.525177001953125, 0.341056823730469]
b2 = 0.314487457275391 -- [0.311737060546875, 0.317237854003906]
b3 = 0.912036895751953 -- [0.901985168457031, 0.922088623046875]
b4 = 0.782825469970703 -- [0.75592041015625, 0.809730529785156]
b5 = 3.01733779907227 -- [3.10484313964844, 2.92983245849609]
b6 = 1.00485610961914 -- [0.968063354492188, 1.04164886474609]

Now, if you exclude b5 (as you can see we didn't bother improving
exception throwing performance in 1.0: it turns out it's needed
also when running nemerle and Java code) we have an overall 80%
improvement. More speedups are expected from the changes we plan to do
to the runrime and jit in the next few months before mono 1.2.

> pystones/second (higher is better)
>     34K    Python-2.3
>     38K    Python-2.4
>     58K    IronPython-0.7 on .NET 1.1
>     67K    IronPython-0.7 on .NET 2.0beta1

I assume you mean 0.6, since 0.7 doesn't run on 1.1.

> the same benchmark with zero Python specific development.  The ability
> to take advantage of these kinds of improvements in the underlying
> platform is a big part of what excites me about running on the CLI.

Yep, it's the reason I advocated people target IL code for dynamic
langauges before I even knew about ironpython:-)

> My plans for getting to IronPython 1.0 don't include any significant
> work on performance optimization.  I think that the performance is
> already good enough and the focus needs to be on CPython compatibility
> as well as really solid support for all of the CLI features.

Some (even limited) support for specialization is needed to get
the real speed boosts, anyway, IMHO. But of course having ironpython run
a wider range of code than it currently does is a better choice to spend
time on.

> This is correct and embarrassing.  I made some stupid changes in moving
> to 0.7 and wasn't running the right regression tests.  In my defense,
> I've had one or two non-technical issues that were distracting me at the
> time.  We'll work on getting pie-thon running again ASAP.

Thanks. Being able to run the standard python tests would be good, too,
to have a grasp of where ironpython is wrt cpython compatibility.

lupus

-- 
-----------------------------------------------------------------
lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better