[IronPython] Microsoft .NET vs. Mono on running IronPython

[Paolo Molaro]

Thanks for the numbers and for the comparisons!

On 04/23/07 Sanghyeon Seo wrote:
> Indeed, if I compare Windows CPython 2.5 numbers and Linux CPython 2.5
> numbers, Windows CPython 2.5 is ~1.2 times faster, most likely because
> Jim's laptop is faster. With a single exception. StringMappings test,
> calling .upper() and .lower() methods on string, is 4 times faster on
> Linux. This could be glibc doing smart optimization. I decided to
> exclude this test in comparisons below.

Check the string representation, I believe on Linux python can be
compiled to 2 or 3 different encodings (likely utf8, utf16, UCS4)
and the encoding used, if different, could explain much of the
speedup.

> Summary:
> 
> >>From these tests, Mono seems to perform comparisons and exception
> handlings better than .NET for running IronPython.
> 
> Mono is 6 times slower on string and unicode concatenation and 4 times
> slower on slicing. It's also 3 to 4 times slower on IronPython
> instance creation.

Yeah, I had a quick look at pybench a few months ago and the major issue
for mono is the garbage collector performance. IronPython is very
alloc-happy in its implementation and this hurts us more than the MS
runtime (for GC microbenchmarks, which some of pybench ends up being
comparable to, the MS runtime is 2-3 times faster than mono).
It is also likely that IronPython has been optimized to follow the MS
.net performance guidelines which don't necessarily match
mono's preference.
We're working on a new GC which will reduce significantly the gap,
expect news in the next few months.

> # How many tests Mono run fast?
> >>> len([1 for x in k if x < 1])
> 10

Well, at least we win somewhere:)

> >>> len([1 for x in k if x > 2])
> 21
> 
> # Three times?
> >>> len([1 for x in k if x > 2])

Typo there, should be a 3

> 9

> 
> These tests, embarassing for Mono are: BuiltinFunctionCalls,
> ConcatStrings, ConcatUnicode, CreateInstances, CreateNewInstances,
> CreateStringsWithConcat, ListSlicing, StringSlicing, UnicodeSlicing.

You'll note that all those are heavy allocators (except maybe
BuiltinFunctionCalls?).

lupus

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