Re: Performance of Integer Multiplication on PIII

["Tim Prince" <tprince at computer dot org>]

----- Original Message -----
From: <pete@ltoi.iap.physik.tu-darmstadt.de>
To: "Tim Prince" <tprince@computer.org>
Cc: <kevin@atkinson.dhs.org>; <gcc@gcc.gnu.org>
Sent: Sunday, November 04, 2001 7:22 AM
Subject: Re: Performance of Integer Multiplication on PIII


>
> > gcc-3.1 has -march=pentium4 for the P4.
> Good
>
> > Of course, subsequent NetBurst versions should reduce a few of the
excessive
> > operation costs

> Now you add the P4, with the result:
>
>   Method   P55C      P6     P4
>   imul     slow     fast   well
> shift&add  fast     slow   preferable for some cases
>
> Here is the rationale:
>
> At page 2-55 in the Intel P4 Optization manual we read: imul incur some
extra
> latency [p. C-13: Latency 14, throughtput 3] due to being executed on
the
> FPU. &
> Ass/Compiler Coding rule 44: Replace imul's by small constant with two
or more
> add & lea instr., especially when imul is part of a dependecy chain.
>
> And on p. 2-54: shift's have longer a latency then on previous
proccessor's
> [p. C-13: Latency 4, throughtput 1]
>
> And specifically: As/Comp. C. Rule 42: if shift is on the critical
path,
> replace it by a sequence of up to three adds. (sic! Not more)
>
So, the cost of shift by 4 should be set less than the cost of 4 adds,
even if this does not exactly agree with the current table, while the
cost of shift by 3 must be more than the cost of 3 adds. This interesting
statement might even be taken as an indication of intent to make future
processors conform with this assessment of shift performance.  Shift by 3
is a frequent case where MSVC code is slow on current P4. Thanks for the
excellent summary of available documents.
> Thus, if (and you could see this in the .s files) gcc uses to much
> equivalent replacement instructions for imul, then, even on the P4,
with his
> (not fully pipelined) imul, your handcoded version runs faster ...
> thus leading us again, to the question, in what respect, the new
gcc-3.0.x
> x86 backend is improved?
Yes, even when there are sequential dependencies, large expansion may
lose due to overflowing trace cache.  Besides, it's useful to have
options which work well on a variety of processors.
>
> - Supports: -march=athlon
> - ?
I know that the SuSE people have been working hard on this.
I only wish it were not so difficult to change the OS on these AthlonMP
SCSI drive boxes which come from Taiwan with Win98 installed.  Sorry to
be OT, but does anything work? SuSE?