|Funny? firstname.lastname@example.org (JUKKA) (1997-04-13)|
|Re: Funny? danwang@atomic.CS.Princeton.EDU (1997-04-16)|
|Re: Funny? pfoxSPAMOFF@lehman.com (Paul David Fox) (1997-04-16)|
|Re: Funny? WStreett@shell.monmouth.com.spamguard (1997-04-18)|
|Re: Funny? email@example.com (William D Clinger) (1997-04-18)|
|Re: Funny? firstname.lastname@example.org (1997-04-18)|
|From:||email@example.com (Herman Rubin)|
|Date:||18 Apr 1997 01:33:20 -0400|
|Organization:||Purdue University Statistics Department|
Daniel Wang <danwang@atomic.CS.Princeton.EDU> wrote:
>> I just created a Visual C++ program under Windows 95 which runs
>> slower when it is optimised for speed. And which runs faster when
>> it is a debug version without any optimisation and lot of extra
>> debug code.
>Just a guess, but sounds like the optimizer is unrolling some loop so that
>the "optimized" code no longer fits in the instruction cache, so you're
>paying a cache hit on every loop. The debug version is probably faster since
>it fits in the cache.
I remember a long time ago when I tried the main loop of a program
which had been written in assembler on the various compilers for a CDC
6500. Following Knuth's article on Fortran optimization, the best
that any conceivable Fortran compiler could do was 45%; to do better
would have required register management across blocks and conditional
calls. The non-optimizing compilers got about 33%, with half the loss
due to not being able to use assembler instructions for one small code
segment. The optimizing compilers got 23% efficiency; they made too
many wrong assumptions.
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
firstname.lastname@example.org Phone: (765)494-6054 FAX: (765)494-0558
Return to the
Search the comp.compilers archives again.