Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!rutgers!husc6!panda!genrad!decvax!tektronix!uw-beaver!ubc-vision!alberta!calgary!radford
From: radford@calgary.UUCP
Newsgroups: net.arch
Subject: Access times of BIG memories
Message-ID: <432@vaxb.calgary.UUCP>
Date: Sat, 11-Oct-86 16:53:39 EDT
Article-I.D.: vaxb.432
Posted: Sat Oct 11 16:53:39 1986
Date-Received: Mon, 13-Oct-86 00:41:37 EDT
References: <600@sdcc12.UUCP> <7960@lanl.ARPA> <5559@decwrl.DEC.COM> <236@ima.UUCP>
Organization: U. of Calgary, Calgary, Ab.
Lines: 29

In article <236@ima.UUCP>, johnl@ima.UUCP (John R. Levine) writes:
> In article <403@vaxb.calgary.UUCP> radford@calgary.UUCP (Radford Neal) writes:
> >... the time required to decode the addresses for your huge
> >memories is logarithmic in the size of the memory.
> 
> Not really true -- memory addresses are not decoded by a tree but more
> typically by broadcasting the address and having all of the memory units
> look for their own addresses in parallel.  More realistically, by the time
> you take into account caches, pipelined buses, interleaved memory and all
> the other speed up tricks commonly done in hardware, the address decode time
> is the least of your problems.
> -- 
> John R. Levine, Javelin Software Corp., Cambridge MA +1 617 494 1400

I'm not a hardware engineer, but when you broadcast the address to a 
number of memory units, doesn't the capacitance of the lines, and hence
the access time, go up *linearly* in the amount of memory, which is
(asymptotically) even worse than the logn time for a decode tree?

I agree that this may not be of practical significance for present-size
memories, but this whole discussion has been about ridiculously BIG memories,
for which I don't think a constant access time can be assumed.

Also, I don't think caches and interleaving help you in this respect. 
Pipelining clearly does, but there are limits if you stick with a basically
Von Neuman (sp?) achitecture.

    Radford Neal
    The University of Calgary