Related articles |
---|
Funny? jukkaj@ping.at (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? will@ccs.neu.edu (William D Clinger) (1997-04-18) |
Re: Funny? hrubin@stat.purdue.edu (1997-04-18) |
From: | hrubin@stat.purdue.edu (Herman Rubin) |
Newsgroups: | comp.compilers |
Date: | 18 Apr 1997 01:33:20 -0400 |
Organization: | Purdue University Statistics Department |
References: | 97-04-067 97-04-089 |
Keywords: | optimize, performance |
Daniel Wang <danwang@atomic.CS.Princeton.EDU> wrote:
><jukkaj@ping.at> writes:
>> 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
hrubin@stat.purdue.edu Phone: (765)494-6054 FAX: (765)494-0558
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.