Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!purdue!mentor.cc.purdue.edu!pur-ee!hankd
From: hankd@pur-ee.UUCP (Hank Dietz)
Newsgroups: comp.arch
Subject: Re: John von Neumann, sqrt instr
Message-ID: <12640@pur-ee.UUCP>
Date: 20 Aug 89 17:02:59 GMT
References: <21353@cup.portal.com> <25643@obiwan.mips.COM> <1513@l.cc.purdue.edu> <2376@wyse.wyse.com> <3312@blake.acs.washington.edu>
Reply-To: hankd@pur-ee.UUCP (Hank Dietz)
Distribution: na
Organization: Purdue University Engineering Computer Network
Lines: 20

In article <3312@blake.acs.washington.edu> lgy@newton.phys.washington.edu (Laurence Yaffe) writes:
...
>2) I'm content if divide is (typically) no more than 5 times slower
>   than multiply.  Most of my programs probably wouldn't care if
>   divide was 100 times slower than multiply, but that's not good
>   enough - a few of my important programs do need a better divide.
...
>5) I'm not a big user of square roots.  As long as square roots cost
>   less than 100 multiplies, I don't think I'd trade faster square roots
>   for slower performance in other ops.
....

Doing this all in software (and restricting ourselves to integer for
simplicity), we managed to get divide to be FASTER than multiply...  but it
doesn't give you modulus/remainder for free.  Yeah, it surprised me too.  I
still haven't been able to find a software technique to make square root
comparably fast.  Anybody got a screamer of a software technique for
computing square root?

							-hankd@ecn.purdue.edu