Re: RAM-CPU Singularity
- From: "Paul E. Black" <p.black@xxxxxxx>
- Date: Wed, 08 Feb 2006 13:09:42 -0500
On Tue, 07 Feb 2006 05:07:35 -0800, yaoziyua wrote:
... I have this idea of RAM-CPU singularity:
That is to say, software applications should sometimes treat the RAM and
CPU resources as one single computing resource, using an idle resource to
compensate the urgent needs of another kind of resource.
Based on space-time tradeoff principles in algorithm design theory, we can
redesign object libraries like STL to be able to adapt to any extremely
unbalanced space-time requirements (e.g. a very fast CPU but very limited
RAM, or a very slow CPU but very rich RAM) and able to re-adapt to a new
requirement on-the-fly. Application frameworks like MFC, VCL or GTK should
also be redesigned to serve this purpose. But the details of resource
management should be transparent to the end developer.
An intriguing idea! I don't know if the trade-off could be made at a
fine grain, like page swapping, but it might work at a coarser grain.
Some computations "memoize" intermediate computations. If memory is
tight, it may be better to recompute more things and memoize fewer.
In artificial intelligence, iterative deepening recomputes space
states instead of storing vast trees in memory.
I've seen proposals to store executables (i.e., binaries, machine
code) in a compressed format. It is faster to read a compressed
executable from the disk and decompress it than to read a normal
executable. That might be executed to binaries in main memory: it may
be cheaper to decompress chunks of code from main memory and cache
them in L2 than to use them straight from main memory if it fills up
the cache. For that matter, it may be faster to run a tiny
"interpreter", which fits in L1, than getting a huge program from main
memory or even L2.
These trade-off could be made at initial run time. That is, the
program's start-up detects whether the execution environment is
memory-rich or computation-rich, then run the branch/version optimized
for that.
-paul-
--
Paul E. Black (p.black@xxxxxxx)
.
- Follow-Ups:
- Re: RAM-CPU Singularity
- From: Karl Klose
- Re: RAM-CPU Singularity
- References:
- RAM-CPU Singularity
- From: yaoziyuan
- RAM-CPU Singularity
- Prev by Date: Call for Papers: IAENG International Workshop on Computer Science (in IMECS 2006)
- Next by Date: The Wikipedia Article On Turing Machines vs. Physical Devices
- Previous by thread: Re: RAM-CPU Singularity
- Next by thread: Re: RAM-CPU Singularity
- Index(es):
Relevant Pages
|
