[Python-Dev] Microsoft speedup (original) (raw)

Duncan Booth duncan@rcp.co.uk
Fri, 09 May 2003 09:19:28 +0100

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 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