Network RAM for Beowulf

Eray Ozkural (exa) erayo at
Sun Aug 26 07:31:06 PDT 2001

Hash: SHA1

On Saturday 25 August 2001 08:51 pm, Thomas R Boehme wrote:
> There are many applications that could make reasonable use of network RAM.
> Basically everything which need more RAM then currently possible and
> therefore has to swap to disk to process the data (database applications,
> gaussian, etc.). The network latency is high compared to memory latency,
> but not compared to disk slatency. There, network beats it by several
> orders of magnitude.
> I know a lot of applications which have swapfiles of several gigabytes,
> beeing able to keep them in memory (and even if it is network ram) can
> speed then up significantly. And not everybody can afford to buy Itaniums
> with more than 4 Gig's of memory.

I don't think you could say that in general. The network is fast for a few 
large messages perhaps but not for many small ones. The problem, IMHO, stems 
from the fact that there is no low level way to transform a serial program to 
a parallel one! The more non-local memory access pattern in the original
application, the worse speed-up you will get. You would get good speedup, it
seems to me, only if the problem is embarrasingly parallel. By speedup here I
mean the ratio of running time to single node/virtual memory. That is, a 
distributed shared memory system -no matter how efficient or optimal- is not 
likely to provide a scalable way to increase memory available for 
applications, especially if you want to utilize more than a single node's CPU 
for large tasks.

I think that is also the same reason why you can use virtual memory for
running some algorithms while it would be infeasible for others.
Theoretically speaking, an out-of-core algorithm can be shown to be
equivalent to a certain parallel architecture.

That is not to say that DSM is a cursed enterprise, but rather that such
methods have to be complemented by parallel programming support.


- -- 
Eray Ozkural (exa) <erayo at>
Comp. Sci. Dept., Bilkent University, Ankara
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see


More information about the Beowulf mailing list