[Python-Dev] Microsoft speedup

[Duncan Booth]

On 9 May 2003 at 0:17, Tim Peters wrote:

> [Duncan Booth]
> > It's not a phenomenal speedup, but it should be pretty low impact if the
> > extra size is considered a worthwhile tradeoff.
> 
> I want to see much broader testing first.  A couple employers ago, we
> disabled all magical inlining options, because sometimes they made critical
> loops faster, and sometimes slower, and you couldn't guess which as the code
> changed, and in that problem domain (speech recognition) the critical loops
> were truly critical so we were acutely aware of compiled-code speed
> regressions.  So I'm not discouraged <wink> that pystone sped up when you
> tried it, but not particularly encouraged either.

I'm not suggesting Guido rush out and change the options right 
now, but I wanted to know whether it would be worth looking at 
this further. For all I know its been discussed and dismissed 
already, in which case there isn't much point my looking 
further at it. Also if the main distribution should move to 
VC7, then it would probably be better to check whether this 
sort of micro tweaking has any effect there before wasting 
time on it. 

I've had plenty of experience myself of changing Microsoft 
compiler options and finding the code then breaks, so I agree 
that it would need much more testing. It also needs more 
testing to see whether it makes any kind of difference to real 
programs as well as benchmarks. If I knew any way to get the 
compiler to tell me which functions it inlined, then it would 
probably also be possible to get most of the speedup by 
explicitly inlining a few functions and avoiding most of the 
hit on the code size.

-- 
Duncan Booth                                     
duncan@rcp.co.uk
int month(char *p){return(124864/((p[0]+p[1]-
p[2]&0x1f)+1)%12)["\5\x8\3"
"\6\7\xb\1\x9\xa\2\0\4"];} // Who said my code was obscure?
http://dales.rmplc.co.uk/Duncan