Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!usc!snorkelwacker!apple!agate!linus!linus!bs From: bs@linus.mitre.org (Robert D. Silverman) Newsgroups: comp.arch Subject: Re: F.P. vs. arbitrary-precision Message-ID: <119733@linus.mitre.org> Date: 11 Sep 90 12:53:26 GMT References: <3755@osc.COM> <4513@taux01.nsc.com> <119244@linus.mitre.org> <6837.26e7ee92@vax1.tcd.ie> <119612@linus.mitre.org> <3977@bingvaxu.cc.binghamton.edu> Reply-To: bs@gauss.UUCP (Robert D. Silverman) Organization: The MITRE Corporation, Bedford MA Lines: 103 In article <3977@bingvaxu.cc.binghamton.edu> vu0310@bingvaxu.cc.binghamton.edu.cc.binghamton.edu (R. Kym Horsell) writes: :In article <119612@linus.mitre.org> bs@faron.UUCP (Robert D. Silverman) writes: :\\\ :>Everyone keeps quoting this '99% of the time' stuff to me. I should :>like to point out that there are applications for which having :>32 x 32 -- > 64 and 64 / 32 = 32 quotient & remainder are absolutely :>essential. Basically, ANYTHING involving multiprecision arithmetic :^^^^^^^^^^^ :>requires these. (on a 32 bit machine that is) : ^^^^^^^^ :\\\ : :Don't you mean `useful' of `efficient' here? : I wish people would refrain from shooting their mouths off about multi-precision arithmetic until they've actually done a significant amount of it. Typically, only having 32 x 32 --> 32 slows down multi-precision arithmetic by about a factor of 10. Not having it can render a machine all but useless for performing certain tasks. :The RISC folks probably have the right attitude here -- only that stuff :that happens a lot, or is _absolutely_, logically _required_ need be :implemented in h/w (either that, or can be `tacked on' to what you Happens a lot by whose definition? Yours? What the hell do you know about how much computation in areas requiring multi-precision actually takes place? The people who do that kind of stuff DON'T talk about it. :were going to do anyway as make no matter to the cost)-- design Take a look at the i860 sometime. People have been parading it as a stellar example of a RISC processor. However, a good hunk of real estate on the chip is taken up by a custom purpose processor whose purpose is to aid graphics programming. Yet the damn thing can't multiply and divide. Repeat after me: Addition, subtraction, multiplication, division. These are the four fundamental operations of arithmetic. Too often within this newsgroup I have observed that many people believe that the entire world of computing is either matrix computations [or related work] or UNIX systems programming [or related work]. It is a very parochial attitude. :time means $$$$ after all, right? Exactly. What good is a machine that takes 10 times as long as it should to compute something, simply because the designer failed to add a few gates to provide integer arithmetic. Jobs requiring integer multiply/divide may only represent a small fraction of the total number of jobs, but they typically have CPU requirements that far exceed those of the other 99%. As I pointed out, I burned over several hundred thousand CPU hours last year. I would wager that this is more than rest of the ALL the readers of this newsgroup used put together. : :int x int -> long isn't _required_ for MP calcs, it's just _convenient_. A factor of 10 in performance isn't mere 'convenience'. It can easily change a computation from one that is feasible to do to one that is not. :For example, the `bc' U*X calculator uses bytes to store pairs :of decimal digits and then uses good old int x int -> int to perform :a paper-and-pencil multiply. 'bc' is just slightly slower than molasses. It is a joke. : :Another technique is using `carryless' modular arithmetic with :appropriate bases (e.g. 2^k+1). Performing divisions in Residue Number representation is nearly impossible. About the only way is to convert to normal representation then convert back. : :So maybe some people burn a _lot_ of cycles doing this sort of :stuff (I do myself as it happens), do the economics of design time, :marketting & area indicate that h/w must support it? Maybe that The time to design a multiplier or divider is nil. Whether the market requires it depends on who you are selling to. If you intend to sell to the gov't for example, you damn well better supply the hardware they need. :P.S. I'm still interested in how much of the Sun Sparc's `bc' is : written in assembler; it's _awful_ fast. So far no This proves how little you know about 'bc'. I have code for the SPARC that beats it by almost two orders of magnitude when performing multi-precise multiplication/division. It's _awful_ slow. -- Bob Silverman #include Mitre Corporation, Bedford, MA 01730 "You can lead a horse's ass to knowledge, but you can't make him think"