Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!decvax!ima!haddock!suitti
From: suitti@haddock.ima.isc.com (Stephen Uitti)
Newsgroups: comp.arch
Subject: Re: Questions on SparcStation 1 performance
Message-ID: <13024@haddock.ima.isc.com>
Date: 10 May 89 16:17:28 GMT
References: <6008@brunix.UUCP>
Reply-To: suitti@haddock.ima.isc.com (Stephen Uitti)
Organization: Interactive Systems, Boston
Lines: 34

In article <6008@brunix.UUCP> jps@cs.brown.edu (John Shewchuk) writes:
>I want to do the following many times:
>   x = f * y;
>Currently x and y are integers and f is floating point number.
>
>In an attempt to speed up a program I tried replacing this with
>   x = (a * y)/b;
>where a and b are integers.  After compiling a loop that has 100,000
>iterations...[it was slower]...
>
>What is going on here?  Intuitively, an integer multiply followed by
>an integer divide should be faster than a convert int to float,
>floating multiply, and convert float to int but this does not seem to
>be the case.

On many architectures with integer & floating hardware support, integer
divide is slower than floating divide.  A float represented by 32 bits
has 24 bits of mantissa.  A 32 bit integer has (surprise) 32 bits.  It
takes less time to divide 24 bit quantities (and do add/subract type things
to the exponent) than to divide 32 bit type things.

It is often the case that divides take lots longer than conversions, and
multiplies don't take time.

On the other hand, if SPARC doesn't have the integer divide in hardware, but
does have hardware floating point, and has to call a routine for the integer
stuff, i'm surprised that its only 5 times slower.

On the PDP-11, one version of the ldiv (might have made it into 2.10 BSD)
routine was coded to use floating point divide for those models of PDP that
had floating hardware.  It was quicker.  There was a snafu about divide
by zero exceptions in an early version.

Stephen.