This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Complex arithmetic improvements?
- To: Martin Kahlert <martin dot kahlert at mchp dot siemens dot de>, N8TM at aol dot com, Sol Foster <colomon at ralf dot org>
- Subject: Re: Complex arithmetic improvements?
- From: Peter Chang <peter at eexpc dot eee dot nott dot ac dot uk>
- Date: Fri, 21 Aug 1998 14:42:34 +0100 (BST)
- cc: etzpc at unix dot ccc dot nottingham dot ac dot uk, egcs at cygnus dot com
- Reply-To: etzpc at unix dot ccc dot nottingham dot ac dot uk
Hope you don't mind me grouping these responses together...
On Fri, 21 Aug 1998, Martin Kahlert wrote:
> One comment: My Pentium Pro seems to do a multiplication as fast as an
> addition (about 2 cycles) So this improvement would be a regression
> in that case.
On Fri, 21 Aug 1998 N8TM@aol.com wrote:
> > Line 1344: /* (a+ib) / (c+id) = ((ac+bd)/(cc+dd)) + i((bc-ad)/(cc+dd)) */
> >
> > this can be improved to prevent avoidable {under,over}flows and loss of
> > precisions
> but you should only need (and desire) to do that when running on an
> architecture without extended precision.
> ____________________
> (ac - bd) + i[ (a+b)(c+d) - ac - bd ]
>
> which is one multiply less but one addition and two subtractions more.
> This is usually faster as multiply is quite slow
>
> That depends on your processor, for sure, as well as whether there are other
> useful operations to be performed in the extra time slots which the simpler
> computation leaves open.
On Fri, 21 Aug 1998, Sol Foster wrote:
> I think you really, really want to time this before you make such claims.
> In the old days, multiplcation was much slower, but that may well not hold
> true anymore. The answer probably varies from platform to platform...
So it would seem that these changes would be architecture-dependent. This
doesn't surprise me in the least. I'm certainly not up-to-date on the
latest fp performances so does anyone have any references or figures for,
say the clock cycles for fp operations on different architectures?
Re: the extended precision - does this cope with differences of many
orders of magnitude. I.e. if (c*c + d*d) overflowed in normal precision,
will extended precision be better? I thought extended precision (on an
x86) only gives you more bits in the mantissa which wouldn't help in the
case highlighted.
Thanks for the replies,
Peter