🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #22599

Re: 64-bit addresses

#22599
From: John Mashey
Date: Sun, 25 Feb 1990 03:19
52 lines
3220 bytes
In article <193@zds-ux.UUCP> gerry@zds-ux.UUCP (Gerry Gleason) writes:
>In article <168@csinc.UUCP> rpeglar@csinc.UUCP (Rob Peglar) writes:
>>In summary, there are lots of codes that could be "scaled" (e.g. finer
>>grids) to consume just about any D-space feasible today.  If the
>>vendors want a piece of that action, >32 bits of D-space is necessary.
>>Not to mention issues like memory bandwidth, I/O rates, etc.  1/2 :-)

>Arn't these typically compute bound problems also?  Doesn't this mean
>supercomputers?  Isn't this discussion about high volume microprocessors?
>
>I don't remember who it was that presented the argument based on the
>length of time taken to zero, let alone process 4G, but this looks like
>a valid line of reasoning.  Just how many MIPS does it take before you
>can process a 4G space in less than a week.  I think we're a still far
>from that point.

Micros (one can argue about what you call high-volume :-) have been
ther for a while: certainly any of the current crop of RISCs have
no problem doing something with 4GB of memory.
For example, consider an M/2000 with a 25MHz R3000 (4Q89).
It can zero memory at 50MB/sec.  4GB / (50 MB/sec) = 80 seconds.

Let's try another one.  If accessing data in reasonable size hunks,
you can certainly get 1MB/sec read rates off vanilla SCSI disks.
(Of course you can do better; I'm picking something really trivial,
without even disk-strping, SMD, or IPI.)
Hence it takes 4000 seconds, or a little over an hour to get
this amount of data from a disk, with vanilla technology.  4GB of
disk is certainly something you can put into a PC/AT-size box
already, or at least very soon, with off-the-shelf stuff.

Finally, if the issue is not having enough physical memory to back up the
real memory, there are already microprocessor systems with 128MB
of memory shipping for a while with 1Mb DRAMS, and they can certainly go
to 512MB with 4Mbits, and there are others around with a factor of 2X
bigger on the way. 

Finally, at least part of the issue here is the ability to use
algorithms that burn up address space, even if they don't necesasrily
touch every bit of data, every time.

In any case, let me make a really conservative bet:
No later than 1991, somebody will purchase:
	a) A microprocessor-based system.
	b) Delivered with 1GB of memory.
	c) And they'll really want more physical memory
	d) And they'll dislike an addressing limit of 2GB-4G.
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	{ames,decwrl,prls,pyramid}!mips!mash  OR  mash@mips.com
DDD:  	408-991-0253 or 408-720-1700, x253
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
Technical Details
Message-ID: <36439@mips.mips.COM>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!mips!winchester!mash
References: <9708@spool.cs.wisc.edu> <20270@cfctech.cfc.com> <36080@mips.mips.COM> <168@csinc.UUCP> <193@zds-ux.UUCP>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!mips!winchester!mash
From: mash@mips.COM (John Mashey)
Newsgroups: comp.arch
Subject: Re: 64-bit addresses
Message-ID: <36439@mips.mips.COM>
Date: 25 Feb 90 03:19:37 GMT
References: <9708@spool.cs.wisc.edu> <20270@cfctech.cfc.com> <36080@mips.mips.COM> <168@csinc.UUCP> <193@zds-ux.UUCP>
Sender: news@mips.COM
Reply-To: mash@mips.COM (John Mashey)
Organization: MIPS Computer Systems, Inc.
Lines: 52