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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4