[Beowulf] Good demo applications for small, slow cluster
deadline at eadline.org
Wed Aug 21 09:45:19 PDT 2013
> Sorts in general.. Good idea.
> Yes, we'll do a distributed computing bubble sort.
> Interesting, though.. There are probably simple algorithms which are
> efficient in a single processor environment, but become egregiously
> inefficient when distributed.
e.g. The NAS parallel suite has an integer sort (IS) that is
very latency sensitive.
For demo purposes, nothing beats parallel rendering.
There used to be a PVM and MPI POVRay packages
that demonstrated faster completion times as more nodes were
> On 8/20/13 12:11 PM, "Max R. Dechantsreiter" <max at performancejones.com>
>>How about bucket sort?
>>Make N as small as need be for cluster capability.
>>On Tue, 20 Aug 2013 maxd at performancejones.com wrote:
>>> Date: Tue, 20 Aug 2013 00:23:53 +0000
>>> From: "Lux, Jim (337C)" <james.p.lux at jpl.nasa.gov>
>>> Subject: [Beowulf] Good demo applications for small, slow cluster
>>> To: "beowulf at beowulf.org" <beowulf at beowulf.org>
>>> <F7B6AE13222F1B43B210AA4991836895236966E9 at ap-embx-sp40.RES.AD.JPL>
>>> Content-Type: text/plain; charset="us-ascii"
>>> I'm looking for some simple demo applications for a small, very slow
>>>cluster that would provide a good introduction to using message passing
>>>to implement parallelism.
>>> The processors are quite limited in performance (maybe a few MFLOP),
>>>and they can be arranged in a variety of topologies (shared bus, rings,
>>>hypercube) with 3 network interfaces on each node. The processor to
>>>processor link probably runs at about 1 Mbit/second, so sending 1 kByte
>>>takes 8 milliseconds
>>> So I'd like some computational problems that can be given as
>>>assignments on this toy cluster, and someone can thrash through getting
>>>it to work, and in the course of things, understand about things like
>>>bus contention, multihop vs single hop paths, distributing data and
>>>collecting results, etc.
>>> There's things like N-body gravity simulations, parallelized FFTs, and
>>>so forth. All of these would run faster in parallel than serially on
>>>one node, and the performance should be strongly affected by the
>>>interconnect topology. They also have real-world uses (so, while toys,
>>>they are representative of what people really do with clusters)
>>> Since sending data takes milliseconds, it seems that computational
>>>chunks which also take milliseconds is of the right scale. And, of
>>>course, we could always slow down the communication, to look at the
>>> There's no I/O on the nodes other than some LEDs, which could blink in
>>>different colors to indicate what's going on in that node (e.g.
>>>communicating, computing, waiting)
>>> Yes, this could all be done in simulation with virtual machines (and
>>>probably cheaper), but it's more visceral and tactile if you're
>>>physically connecting and disconnecting cables between nodes, and it's
>>>learning about error behaviors and such that's what I'm getting at.
>>> Kind of like doing biology dissection, physics lab or chem lab for
>>>real, as opposed to simulation. You want the experience of "oops, I
>>>connected the cables in the wrong order"
>>> Jim Lux
>>Beowulf mailing list, Beowulf at beowulf.org sponsored by Penguin Computing
>>To change your subscription (digest mode or unsubscribe) visit
> Beowulf mailing list, Beowulf at beowulf.org sponsored by Penguin Computing
> To change your subscription (digest mode or unsubscribe) visit
> Mailscanner: Clean
More information about the Beowulf