From: Hans-Bernhard Broeker 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 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.