From:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: [long] gcc performance and possible bug
Date:	25 Apr 2000 12:50:10 GMT
Organization:	Aachen University of Technology (RWTH)
Lines:	23
Message-ID:	<8e44a2$ag7$1@nets3.rz.RWTH-Aachen.DE>
References:	<39046544 DOT ADB90632 AT inti DOT gov DOT ar>
NNTP-Posting-Host:	acp3bf.physik.rwth-aachen.de
X-Trace:	nets3.rz.RWTH-Aachen.DE 956667010 10759 137.226.32.75 (25 Apr 2000 12:50:10 GMT)
X-Complaints-To:	abuse AT rwth-aachen DOT de
NNTP-Posting-Date:	25 Apr 2000 12:50:10 GMT
Originator:	broeker@
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

salvador <salvador AT inti DOT gov DOT ar> wrote:

>   I found the problem, when you make the value a constant it is stored
> in the code segment, too close to the code that is executed. It looks like
> that's close enough to be inside the pipeline (probably because the CPU
> is fetching groups of aligned bytes, not just code). Looks like K6 does some
> pipeline flush when you read/write data that is inside the pipeline (or
> perhaps a pre-fetch buffer is a better name for it).

This should not usually be any big speed problem, unless you *write*
into the middle of the code segment, i.e. you violate the const-ness
of those variables. For all other cases, the CPU should always be able
to notice that this variable is only read, not written to. Only
writing into the middle of the .text segment would trigger the code
cache/prefetch queue to have to be nuked and refilled from scratch, in
the worst case.




-- 
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.

- Raw text -