Movatterモバイル変換
[0]ホーム
[Python-Dev] Re: Python 2.1 slower than 2.0
Tim Peterstim.one@home.com
Mon, 29 Jan 2001 22:57:07 -0500
Note that optimizing compilers use a pile of linear-time heuristics toattempt to solve exponential-time optimization problems (from optimalregister assignment to optimal instruction scheduling, they're all formallyintractable even in isolation).When code gets non-trivial, not even a compiler's chief designer canreliably outguess what optimization may do. It's really not unusual for ahigher optimization level to yield slower code, and especially not when thesource code is pushing or exceeding machine limits (# of registers, # ofinstruction pipes, size of branch-prediction buffers; I-cache structure;dynamic restrictions on execution units; ...).[Jeremy]> ...> One of the differences between -O2 and -O3, according to the man page,> is that -O3 will perform optimizations that involve a space-speed> tradeoff. It also include -finline-functions. I can imagine that> some of these optimizations hurt memory performance enough to make a> difference.One of the time-consuming ongoing tasks at my last employer was runningprofiles and using them to override counterproductive compiler inliningdecisions (in both directions). It's not just memory that excessiveinlining can screw up, but also things like running out of registers and soinserting gobs of register spill/restore code, and inlining so much codethat the instruction scheduler effectively gives up (under many compilers, asure sign of this is when you look at the generated code for a function, andit looks beautiful "at the top" but terrible "at the bottom"; some cleveroptimizers tried to get around that by optimizing "bottom-up", and then itlooks beautiful at the bottom but terrible at the top <0.5 wink>; otherswork middle-out or burn the candle at both ends, with visible consequencesyou should be able to recognize now!).optimization-is-easier-than-speech-recog-but-the-latter-doesn't-work- all-that-well-either-ly y'rs - tim
[8]ページ先頭