Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!husc6!encore!knighten From: knighten@Encore.com (Robert L. Knighten) Newsgroups: comp.arch Subject: Re: F.P. vs. arbitrary-precision (was: Killer Micro II) Message-ID: Date: 7 Sep 90 22:06:54 GMT References: <3755@osc.COM> <4513@taux01.nsc.com> <119244@linus.mitre.org> <1990Sep6.224018.17701@odin.corp.sgi.com> Sender: news@Encore.COM Reply-To: knighten@encore.com (Bob Knighten) Organization: Encore Computer Corp., Marlborough, MA Lines: 27 In-reply-to: bruceh@sgi.com's message of 6 Sep 90 22:40:18 GMT In article <1990Sep6.224018.17701@odin.corp.sgi.com> bruceh@sgi.com (Bruce R. Holloway) writes: . . . Actually, if you did statistics on numerical programs (maybe you have), you would find that divide occurs much less frequently than the others. So those guys that sell multiplier-accumulator chips are right, because even if it takes 10x longer to divide, it probably occurs 10x less frequently anyway. . . . This is one of those "which comes first" issues I've discussed with quite a few people. When working on numerically intensive code that needs to be fast I have always avoided divide when possible because it is so slow (and getting slower relative to the other instructions!) This means that such things as rational function approximations are avoided. But why is divide so slow. The hardware architects with whom I have discussed this have said, "Sure, we could do a fast divide, but it would take a lot of gates and no one uses it." And no one uses it because it is slow and . . . Has anyone done careful studies of the actual value of a fast divide (integer or floating point)? -- Bob Knighten Encore Computer Corp., 257 Cedar Hill Street, Marlborough, MA 01752 Internet: knighten@encore.com (508) 460-0500 ext. 2626 uucp: {bu-cs,decvax,gould}!encore!knighten