Xref: utzoo comp.lang.misc:3571 comp.arch:11710
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!wugate!uunet!zephyr.ens.tek.com!orca!frip!andrew
From: andrew@frip.WV.TEK.COM (Andrew Klossner)
Newsgroups: comp.lang.misc,comp.arch
Subject: binary isn't faster (was Re: Fast conversions, another urban myth?)
Message-ID: <4912@orca.WV.TEK.COM>
Date: 10 Oct 89 18:35:38 GMT
References: <832@dms.UUCP> <688@UALTAVM.BITNET> <1989Sep25.184425.20936@utzoo.uucp> <2261@csadfa.oz>
Sender: nobody@orca.WV.TEK.COM
Reply-To: andrew@frip.wv.tek.com
Followup-To: comp.lang.misc
Organization: Tektronix, Wilsonville, Oregon
Lines: 31

George Gerrity (gwg@csadfa.oz) writes:

	"... radix 2 or a power thereof has a decided edge over
	decimal.  That is, you can get a better performance with binary
	for a given cost, compared with decimal, or you can achieve a
	fixed performance for a lower cost."

Here's where the argument breaks down.  Binary doesn't necessasrily
give better performance than decimal.  A contrived example:

	dcl gross_income fixed decimal(8,2);
	dcl tax_to_pay   fixed decimal(8,2);
	dcl tax_rate     fixed decimal(3,3);

	tax_rate = .097;	/* tax rate is 9.7% */
	tax_to_pay = gross_income * tax_rate;

To do this last computation using scaled binary, you start with an
integer multiply instruction, giving a result which can be as large as
10^6 (one million dollars) and which is scaled in units of 1/10^5.  You
can't represent this in a 32-bit word, so you go to two 32-bit words.
Then you have to divide by 1000 to re-scale to units of 1/10^2.

Have you priced a division lately?  I'll go a long way to avoid the
need to divide into a 64-bit number.  The RISC chip in my box (an
88100) doesn't do this in hardware, so there I am doing multi-precision
binary division in software -- just the sort of slow, fussy work that I
was supposed to avoid by using binary representations.

  -=- Andrew Klossner   (uunet!tektronix!frip.WV.TEK!andrew)    [UUCP]
                        (andrew%frip.wv.tek.com@relay.cs.net)   [ARPA]