[Beowulf] Good demo applications for small, slow cluster

[Peter St. John]

Regarding
"...There are probably simple algorithms which are
efficient in a single processor environment, but become egregiously
inefficient when distributed..."
What about the old random number generator: take a 16 bit seed, square it,
take the middle 16 bits, and repeat. They'd want a large number in order
(so you can repeat an experiment, or a run of a model, with the same
"random" numbers), and it's easy to computer sequentially; but if you want
a million of them it would be nice to distribute the job, but I don't think
you can. But maybe "can't parallelize" isn't the same as "badly inefficient
to parallelize".
But I'd use something like that (besides the famous example that 9 women
can't make a baby in one month) as an algrorithm that has to be done
sequentially.
Peter



On Wed, Aug 21, 2013 at 10:10 AM, Lux, Jim (337C)
<james.p.lux at jpl.nasa.gov>wrote:

> 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.
>
> Jim
>
>
>
> On 8/20/13 12:11 PM, "Max R. Dechantsreiter" <max at performancejones.com>
> wrote:
>
> >Hi Jim,
> >
> >How about bucket sort?
> >
> >Make N as small as need be for cluster capability.
> >
> >Regards,
> >
> >Max
> >---
> >
> >
> >
> >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>
> >> Message-ID:
> >>      <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
> >>effect.
> >>
> >> 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
> >http://www.beowulf.org/mailman/listinfo/beowulf
>
> _______________________________________________
> Beowulf mailing list, Beowulf at beowulf.org sponsored by Penguin Computing
> To change your subscription (digest mode or unsubscribe) visit
> http://www.beowulf.org/mailman/listinfo/beowulf
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.beowulf.org/pipermail/beowulf/attachments/20130821/c310c7e1/attachment.html>