Path: utzoo!attcan!uunet!dg!rec
From: rec@dg.dg.com (Robert Cousins)
Newsgroups: comp.arch
Subject: Re: Questions on SparcStation 1 performance
Message-ID: <172@dg.dg.com>
Date: 15 May 89 13:59:43 GMT
References: <6008@brunix.UUCP> <13024@haddock.ima.isc.com>
Reply-To: rec@dg.UUCP (Robert Cousins)
Organization: Data General, Westboro, MA.
Lines: 69

In article <13024@haddock.ima.isc.com> suitti@haddock.ima.isc.com (Stephen Uitti) writes:
>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.  
>
>Stephen.

There are numerous examples of "hot" processors which have little or no
support for integer divide.  If memory serves me correctly, the CDC 6xxx,
7xxx and 17x did not have integer divide instructions.  It was common for
a special instruction sequence to be generated instead which used a floating
point divide.  This make much sense when you realize two trends in computing:

	1.	In Fortran, there are relatively few integer divides in
		the FP heavy code these machines were designed to speed
		up.  The trend to Pascal, C and Ada has changed all of that,
		but many of today's older architectures still have their
		roots in 1966's Fortran IV standard.

	2.	Division/Modulo operations have been the source of numerous
		arguements from the early days.  The early GE computers
		had hardware divide but were forced to modify the fortran
		compiler to use a subroutine because it gave the wrong
		result ("wrong" as in different than software expected but
		numerically correct).  This is reflected today in the
		various language standards which provide differing 
		standards.  Ada provides both the REMAINDER and MOD
		operations which are almost (but not quite) identical.

Just as several RISC processors do not provide direct support for integer
multiply but instead depend upon a multiply iterate instruction sequence,
a similar divide iterate instruction makes sense for some applications.
Since it is possible to factor some constant divisions into faster
sequences of shifts, a smart compiler can still succeed in making
these divide weak machines perform well in some cases.

It has been my personal hobby to work on numerical applications such
as primes and factorials.  In my work, I have found it important that
both results of a division be available:  the quotient and remainder.
(I have historically used machines with EXPENSIVE division operations
making it important to avoid repeating the division.)  Careful management
of arguments and algorithms can bring about substantial performance differences.

Even today, high performance processors such as the 88000 use the floating
point units for integer division operations.  If you disable the floating
point unit on an 88100 and then attempt a division operation, you will 
trap!  (Since the FP unit is built into the CPU, this is a truly artificial
situation.)

Robert Cousins

Dept. Mgr, Workstation Dev't.
Data General Corp.

Speaking for myself alone.