Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!caip!clyde!cbatt!ihnp4!inuxc!pur-ee!uiucdcs!ccvaxa!preece From: preece@ccvaxa.UUCP Newsgroups: net.arch Subject: Re: VERY LARGE main memories Message-ID: <5100122@ccvaxa> Date: Fri, 5-Sep-86 16:07:00 EDT Article-I.D.: ccvaxa.5100122 Posted: Fri Sep 5 16:07:00 1986 Date-Received: Sat, 6-Sep-86 20:49:47 EDT References: <2017@sdcsvax.UUCP> Lines: 39 Nf-ID: #R:sdcsvax.UUCP:2017:ccvaxa:5100122:000:1687 Nf-From: ccvaxa.UUCP!preece Sep 5 15:07:00 1986 I don't claim to know where the cost-benefit curve lies, but there clearly are a lot of problems whose solutions naturally involve huge address spaces: databases, number crunching on huge arrays, image analysis, many kinds of things that fall into connectionist models, etc. For problems like that, solutions on systems with less memory than the address space of the problem will involve some kind of mapping between secondary memory and physical memory. That means they go slow. If memory is "cheap enough" it is obviously preferable to have that memory be physical memory. The definition of "cheap enough" depends on the importance of the problem, the time pressure on its solution, and your budget. Saying that there is a constant that defines the maximum useful amount of memory is simply stating your interpretation of those governing factors. The original note limited the question to single-user systems. Even in that context, though, there is an obvious answer to the complaint that you can't access memory that fast: get more processors and share the memory among them. N years in the future, when processors are available in 1M-processor chips (that is, one chip=1 million processors), it will seem pretty silly to be talking about whether a T of memory is too much, just as now it's pretty silly to be talking about whether a G is too much. There's a simple law governing all of computing [don't ping me on the obvious caveats and quibbles, this is the kind of law that's supposed to be over-broad but simple]: There can't be too much memory and no processor is too fast. -- scott preece gould/csd - urbana uucp: ihnp4!uiucdcs!ccvaxa!preece arpa: preece@gswd-vms