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)

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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)

<snip>
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).
</snip>

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?

-Nathan Ernst


_______________________________________________
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
_______________________________________________
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Reply via email to