Sender: wolfi AT netsurf213 DOT neuss DOT netsurf DOT de
Message-ID: <3917AF5A.FF5C82B2@neuss.netsurf.de>
Date: Tue, 09 May 2000 08:25:30 +0200
From: Wolfgang Formann <w DOT formann AT netsurf213 DOT neuss DOT netsurf DOT de>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.8 i586)
X-Accept-Language: German, de, en
MIME-Version: 1.0
To: pgcc AT delorie DOT com
Subject: Re: pgcc and egcs alignment -- function, basic block and string
References: <20000130211158 DOT D641 AT cerebro DOT laendle> <Pine DOT LNX DOT 4 DOT 21 DOT 0002022017450 DOT 16833-100000 AT hq DOT alert DOT sk> <20000203131955 DOT D12247 AT atrey DOT karlin DOT mff DOT cuni DOT cz> <389C6000 DOT 5B79248 AT neuss DOT netsurf DOT de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: pgcc AT delorie DOT com

Jan,

seems to be the same with Athlon, at least with this one
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 2
model name      : AMD Athlon(tm) Processor
stepping        : 1
cpu MHz         : 698.660058

here again, I got some speedups when I rearranged the code to have no
instructions crossing any 16byte border.

Wolfgang

Wolfgang Formann wrote:
> 
> Jan Hubicka wrote:
> >
> > > On Sun, 30 Jan 2000, Marc Lehmann wrote:
> > >
> > > > > 10% is really a lot, inside a loop, which takes (about) 25 * 35 cycles.
> > > >
> > > > That's very much. I doubt it really is the three nops, but...
> > >
> > > Well, AFAIK K6 family (especially K6-1) is pretty sensitive to
> > > splitting insns over cache line boundary. Such cases slow down the
> > > decoding of instruction. Considering importance of decoders'
> > > performance on K6 and loop length (only 25-35 cycles as being said)
> > > and assuming some longer insns was split this way, 10% difference
> > > is IMHO possible.
> > I've measured more than 10% speedups in number of loops by patch assing
> > .p2align 5,,<opcode+modrm length> before each instruction.
> > I have made patch to egcs. It is not in the mailnine (I will re-try to
> > submit updated version soon), but you may find in the mailing list
> > archives (July or August)
> >
> > The penalties are not clean (even to the AMD folks), but they are believed
> > to be following:
> > insn opcode crossing cache line boundary (32 bytes) - 1 cycle + insn becoming vector decoded (minimally 2 cycles + lost parallelism)
> > insn opcode crossing ifetch buffer (16 bytes) - 1 cycle at lest
> > insn mod/rm byte separated by cache line boundary - 1 cycle + lost parallelism in case insn ought to be scheduled to first decoder
> > insn mod/rm byte separated by ifetch buffer - lost prallelism in case insn ought to be scheduled to first decoder
> 
> This seems to be right, so after hacking one more day, I get another
> ~10%
> of improvement. All together crypt586.pl is improved from the original
> 13780 to 18912 crypts/second on my good old K6-I/233 :-)
> 
> But there is still a large number of question marks!
> Thanks!
> 
> >
> > This is not official. Even the AMD's K6 emulator is incorrect in handling these
> > situations and probably no-one knows how it really works.
> > Especialy the penalties for first case are extreme. In other cases padding
> > by nops may or may not be worthwhile. Reordering insns/moving whole loop
> > body helps in all cases, but it is out of reach of gcc's optimizers.
> >
> > Does anyone know how the situation looks for PPro? I tought that only
> > ifetch buffers matters and that they are missaligned (so when long insn
> > is crossing the end of current ifetch, next one starts at the start of
> > that insn), so .p2align strategy don't works there, or am I mistaken?
> > >
> > > BTW: On my K6-2, I get best performance when loops and functions are
> > > aligned to 8 byte boundary. But this (as well as cache line end issues)
> > > deserves more testing, so I will do so during weekend.
> > >
> >
> > I've just re-started by work on the K6 support for egcs (and cleaning up
> > the code and looking for common bits with Athlon I need for my contract)
> > so please keep me informed.
> >
> > Honza
> > > Have a nice day
> > >
> > > ------------------------------------------------------------------------------
> > > Martin Ockajak a.k.a. Mandos  <mandos AT hq DOT alert DOT sk>  http://hq.alert.sk/~mandos
> > > "The goal of Computer Science is to build something that will last at
> > > least until we've finished building it."