Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!MCC.COM!MCC.COM!AI.Gadbois
From: AI.Gadbois@MCC.COM (David Gadbois)
Newsgroups: comp.arch
Subject: Re: 64-bit addresses
Message-ID: <19900223050325.4.GADBOIS@APRIORI.ACA.MCC.COM>
Date: 23 Feb 90 05:03:00 GMT
References: <986@m1.cs.man.ac.uk> <9708@spool.cs.wisc.edu> <20270@cfctech.cfc.com> <36080@mips.mips.COM> <168@csinc.UUCP>
Reply-To: gadbois@CS.UTEXAS.EDU
Lines: 50
Posted-Date: Thu, 22 Feb 90 23:03 CST
To: comp-arch@CS.UTEXAS.EDU


    From: mshute@r4.uucp (Malcolm Shute)
    Date: 21 Feb 90 12:22:22 GMT
    
    >In article <36080@mips.mips.COM>, mash@mips.COM (John Mashey) writes:
    >> Barry has a good analysis, but I'd observe a few other things:
    and proceeds to observe that most people who think they want 64bit
    addressing haven't thought through their reasoning, and realised that
    they *could* live without it if they redesigned their proposed solution
    properly.  But isn't this the point in current computer usage: hardware
    is cheap, salaries are expensive.  If there is a 'natural' sledgehammer
    approach which will ensure that the job is finished quickly, and
    correctly (this follows from it being a 'natural' approach wrt to the
    human minds that designed it) then it beats the more thought-intensive
    solutions.

Shute has pointed out a tradeoff that I think is too often overlooked.
Having needlessly big address spaces makes it possible to get answers to
problems that would be too expensive in human time to solve otherwise.

For example, lately I have been doing manipulations of address traces.
The (brute force) algorithms I use to get the results need space
potentially much larger than the size of the traces.  That's OK for
small data sets, but I would be happy to look at gigabytes of addresses.

With my dumb algorithms, I can set up a data run in a few hours, get it
started, and then go play nethack until it finishes.  On the other hand,
if I had to worry about running out of address space, the setup time
goes from hours to days.  I'd have to bend over backwards writing
intermediate results to the filesystem or coming up with tricky
space-efficient algorithms.  It's just not worth it.

Also, as Shute implies, the small address space aproach constraints have
greater potential for incorrect results.  Lacking the will and the
verification techniques, how do you find subtle bugs in gigabytes of
output?

I wouldn't even mind if it took a week or two to process a really big
trace.  It would be a waste of machine time, not my time.

(Actually, even if I had a processor with a 64-bit address space, I
certainly couldn't afford all the secondary storage necessary to use the
whole space.  Assuming that backing store costs, say, as little as $1.00
per megabyte, I'd still have to buy $17,592,186,044,416.00 worth of
disks to use every bit in the address space.  Even a measly 40-bit space
would eat up $1,048,576.00 in disk space at those prices.)

--David Gadbois
various affiliations
Disclaimer: I'm not a real computer architect, but I play one in grad school