Newsgroups: comp.lang.apl
Path: watmath!watserv2.uwaterloo.ca!torn!utzoo!helios.physics.utoronto.ca!utcsri!rpi!zaphod.mps.ohio-state.edu!darwin.sura.net!haven.umd.edu!socrates!socrates!rockwell
From: rockwell@socrates.umd.edu (Raul Deluth Miller-Rockwell)
Subject: Re: j 5.1, pc, 386
In-Reply-To: dgil@ipsaint.ipsa.reuter.COM's message of 28 Sep 92 04:00:04 UT
Message-ID: <ROCKWELL.92Sep30192223@socrates.umd.edu>
Sender: rockwell@socrates.umd.edu (Raul Deluth Miller-Rockwell)
Organization: Traveller
References: <1992Sep28.045728.6501@yrloc.ipsa.reuter.COM>
Date: Thu, 1 Oct 1992 00:22:23 GMT
Lines: 42

Robert Bernecky:
   > In this case, it's heap fragmentation and virtual storage problems.

David Gillett:
       Is it?  I would have thought it was something like: How can my
     program make run-time choices between size-intensive and
     speed-intensive approaches based on available resources?  I do
     agree that simply implementing an exact analogue of quadWA is not
     the answer, but I think we disagree about the real question.

If the question is "how should we deal with finite storage limits",
may I suggest an entirely different class of thought?

Memory, with current technology, is generally a complex hierarchy of
storage devices with varying speed/cost ratios.  You have registers,
caches, "memory", more caches, disk, tape, ...  And, generally, if
you're capable of putting up with slower times you can gain access to
greater storage.

One obvious solution to this problem is to bring more storage into the
picture, so degradation due to "not enough memory" becomes a time
restriction rather than a catastrophic failure.  This would make
estimates of time-to-compute somewhat more complex than a "flat memory
of infinite size", but it should be fairly useful.

I've been on a variety of machines which have crashed due to
insufficient resources allocated for system use.  I've seen this
happen on Suns, DECs, IBMs, and I suspect I've seen it on HPs.  As
systems get larger and more complex, I suspect that overall system
load will be far more critical than the niceties of how an address
space is mapped to physical devices.

APL is a nice notation for expressing operations on large quantities
of data -- it seems to me that it would be even nicer if this data
could live in a file system without having to express the nitty gritty
details of how it's cached in silicon memory.  [I think an
implementation of J "locale" would be a good step in this direction.]

Comments?

-- 
Raul Deluth Miller-Rockwell                   <rockwell@socrates.umd.edu>
