Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site digi-g.UUCP Path: utzoo!watmath!clyde!cbosgd!ihnp4!stolaf!umn-cs!digi-g!dan From: dan@digi-g.UUCP (Dan Messinger) Newsgroups: net.lang.c Subject: Re: Why 'C' does not need BCD... Message-ID: <423@digi-g.UUCP> Date: Tue, 4-Dec-84 11:49:52 EST Article-I.D.: digi-g.423 Posted: Tue Dec 4 11:49:52 1984 Date-Received: Mon, 10-Dec-84 02:40:17 EST References: <166@harvard.ARPA> <247@desint.UUCP> Reply-To: dan@digi-g.UUCP (dan) Distribution: net Organization: Digigraphic Systems Corp., Mpls, MN Lines: 52 Summary: In article <247@desint.UUCP> geoff@desint.UUCP (Geoff Kuenning) writes: >A seek once out of every 500 transfers (which a well-designed filesystem >can achieve) does not seriously impact performance. I find this incredible! Do you have a disk drive for each application? With many programs trying to access the same drive, I can't imagine how you could get 500 transfers/seek. How many drives have that many blocks per cylinder? How many times do you rewrite the same block? >So? Ever try to swap out 1 MB on a 5-1/4" Winchester? For that matter, ever >try to swap out 2 MB on an Eagle? We are talking transfer times in SECONDS >here, compared to seek times in the 20-100ms range. So what happened to your well-designed filesystem? A 5-1/4" winchester can transfer ~1.3 MB/second, and an Eagle is ~1.8 MB/second. A second, but not secondS. >>You can do your arithmetic with 32 bits and store data as 24 bits >>on disk (that's what UN*X used to do on PDP-11's). > >This is the "shooting down" of your argument that I mentioned above. As >soon as you have to take 24-bit numbers, convert them to 32 bits, and >convert them back to 24 for output, you have lost any possible speed >advantage that binary might have given you. 6-digit BCD is much faster. Are you serious? You think that adding a 00 or FF byte to the begining of the binary number is going to take LONGER than doing BCD math? Do you know what BCD looks like in the computer? Have you tried writting BCD math routines? Are you a programmer? BCD verses binary boils down to two issues. First, the well known space vs. time trade-off. By using 4-byte binary instead of 3 byte BCD, the program can run much faster. If there are a lot of numbers involved, this is no small issue. By storing only 3 bytes on disk, the extra disk space can be elliminated, with some loss in performance. But I assure you that converting a 24 bit int to a 32 bit int takes less time than performing a single BCD add. And how many BCD operations are going to be performed on that number while it is in memory? Second is portability. A BCD math library would perform more consistantly across a wider variaty of computers. As long as a machine can address 8 bit bytes, the BCD math package should work. 32 bit ints may not be available on some machines. But BCD being faster than binary? I suggest that you find a local software engineer and ask him to explain it to you. (I'm sure it will amuse him/her) I'm not saying that binary is alwasy the better way. I'm just saying that your reasons are absolutely ludicrous. Dan Messinger ihnp4!umn-cs!digi-g!dan