Message-ID:	<3CFD46D4.9070503@deadgoths.com>
From:	David Carson <dc AT deadgoths DOT com>
User-Agent:	Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0rc3) Gecko/20020523
X-Accept-Language:	en-us, en
MIME-Version:	1.0
Newsgroups:	comp.os.msdos.djgpp,comp.lang.c++
Subject:	Re: [OT] Optimization and operator&&
References:	<3CFCB642 DOT 252CFFF7 AT bigfoot DOT com>
Lines:	24
Date:	Tue, 04 Jun 2002 23:01:09 GMT
NNTP-Posting-Host:	144.137.50.170
X-Complaints-To:	news AT bigpond DOT net DOT au
X-Trace:	news-server.bigpond.net.au 1023231669 144.137.50.170 (Wed, 05 Jun 2002 09:01:09 EST)
NNTP-Posting-Date:	Wed, 05 Jun 2002 09:01:09 EST
Organization:	BigPond Internet Services (http://www.bigpond.net.au)
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

Alex Vinokur wrote:
> A program below measures performance (time) :
>   * of operator&& and operator+
>   * with automatic and static unsigned int
>   * with optimizations : No optimization, O1, O2, O3
> 
> We can see that Optimization causes
>   an increase in elapsed time for operator&& .
> Any explanation?

Well, look at the assembly code that gcc is generating for both the 
optimised and non-optimised case. It's only a single instruction within a 
loop, you can figure out the difference given a few minutes and the 
appropriate manual (all of Intel's are available on their website) even if 
you're not an assembly guru.

What CPU are you using? Betcha gcc is producing code which would have been 
faster on some difference CPU of the Pentium family..

p.s. && does not mean "OR".

Cheers!
David...

- Raw text -