[IronPython] Sin and Sqrt performance (Chris Trimble)

Dino Viehland dinov at exchange.microsoft.com
Tue Apr 18 01:45:03 CEST 2006

I was running on a pre-beta 6 build, so there could be some slight differences.  I also had made a change to switch from range to xrange.

It could be that switching to xrange lets the faster + path start to matter, otherwise working set issues could dominate.  Tough to say...

I wonder if Boo could have optimized away the entire loop (in theory they could notice the calls into Math and optimize those)...  Note the 4ms is basically equal to zero because the precision of DateTime.Now isn't very good.

Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Chris Trimble
Sent: Monday, April 17, 2006 4:34 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Sin and Sqrt performance (Chris Trimble)

On 4/17/06, Dino Viehland <dinov at exchange.microsoft.com> wrote:
>   Changing the code to do j = j + xyz yields about a 25% perf
> improvement for me though.

Thanks for looking into this Dino.  Oddly, I get the opposite result
for this case!  I ran the test 3x with j = j + and 3x with j +=.  I

j = j + .... 5.719s  5.656s  5.547s
j +=  .....  5.625s  5.578s  5.406s

Is there an optimization flag I should be using?

> Which brings me back to the cost of being dynamic.
> All of these small improvements (not that 35% is something
> to look down at) won't get us that close to C#'s performance.
> What would be better here for the long-term is adding type
> inference support to IronPython so we can do this all very fast,
> and fall back to the slow path if things change due to being dynamic.

Given what you said here I decided to give Boo's type inference a try
and see what it came up with.  At the end of the message is my (hacked
up) code in Boo.  Odd result again... the resulting timing comes out
to be _faster_ than C# (~4ms compared to 10ms for C#).  Could be Boo
might be running on CLR 1.1 while C# is running on 2.0, haven't
bothered to verify.  Anyway, unless I'm doing something horribly
wrong, it's a good datapoint.

Thanks again for the explanation, it's been very helpful... and great
work on IP!

 - Chris


def py_fpfunc_test(reps as int):
    j = 0.0
    i = 0
    while i < reps:
        j += System.Math.Sin( j )
        j += System.Math.Sqrt( j )
        j += 2.72392032032;
        i += 1
    print j

def do_all_timing():
    start = System.DateTime.Now
    end = System.DateTime.Now
    print("{0} ({1} reps): {2}" % ("fpfunc", 5000000,
(end.Ticks-start.Ticks) / 1000000.0))

users mailing list
users at lists.ironpython.com

More information about the Ironpython-users mailing list