[IronPython] Sin and Sqrt performance (Chris Trimble)
dinov at exchange.microsoft.com
Tue Apr 18 01:54:09 CEST 2006
Yes, I would think the likelihood would be the two types being the same :) But currently we check for int, BigInteger, and complex before we check for double for some reason... it's just silly.
We don't currently do any magic w/ literals to treat them specially... They just become objects and then later the runtime does its normal logic for dealing w/ objects. But this would be the place to start for type inference.
The problem w/ the loop optimizations you describe is the code is already compiled by the time we come to the 1st iteration. If we had some hints (e.g. there was a literal) we could have code that generates the guess and falls back to the slow path if that doesn't work. But if we had a literal we could hint off (or a hint that flowed from a literal) then we'd be in business.
Given that we're doing nothing today there's lots of room for improvement here :).
I'm using Visual Studio 2005 Team Suite to do the profiling using it's sampling profiler. Its pretty simple to use and gets the job done.
CLR Profiler does include a call graph I believe but I don't think it gives you the timing information that VS does. I end up using CLR Profiler when I need to drill down into allocations more closely (and WinDbg when I need to debug the CPython weakref tests :) ).
Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Nathan R. Ernst
Sent: Monday, April 17, 2006 4:41 PM
To: 'Discussion of IronPython'
Subject: Re: [IronPython] Sin and Sqrt performance (Chris Trimble)
I looked at this under the profiler and there is some sillyness in
IronPython that can yield a ~10% perf gain on this micro benchmark (for
example in place add of floating point doubles checks for 3 other types
before seeing if the other type is a double - most likely it's a double and
we should check that first).
Couple of toughts on this:
Wouldn't it be the common case that the types on the lhs and rhs of an
operator are the same? Also, in the case where the rhs is a literal, don't
you *know* what the type is implicitly (I'm afraid I don't know if this is
being taken into consideration currently)?
It also comes to mind that successive iterations through a loop are likely
to yield the same types for function alls. Might it be possible to cache
the type information, and recalculation only if a problem is encountered
(such as an int became a long integer, or an iterator that was returning
ints started returning strings)?
On a tangential topic, Dino, what are you using to profile the code? All
I'm aware of is the CLR profiler, but doesn't this only profile allocations?
users mailing list
users at lists.ironpython.com
More information about the Ironpython-users