availability of Memory compression routine

[Dean Johnson]

First of all, I am not sure that you will get much in the way of
compression and at a quite high computational cost. With relatively
random data, I would suspect that it would look like just a bunch of
randomly distributed bits and not have anything to really interesting to
compress, given that you probably don't want to use lossy methods. ;-)

Before you launch into working on this idea, dump an example of the raw
data to a file and then use the different compression methods to see if
you get anything at all.

As for the communications piece, isn't an mpi_broadcast just a loop over
a send to the available nodes (ie. a mere convenience). Perhaps you
could do a multicast to the nodes and avoid the multiple streams. I
believe that it will take a bit of work, but the amount of data flowing
out the single interface of the dispatching node will be reduced
dramatically. You can actually afford to have a lot of retransmits and
still break even. A nice thing about the multicast is that it scales
nicely, as opposed to an old fashion broadcast. Once you saturate the
outgoing interface, you don't have anywhere to go. You might also think
about splitting the cluster onto different switches and putting multiple
interfaces in the dispatching box. Based on your hardware, you can do
things to make your existing algorithm work much better with very little
cost. We had a 3com switch with a gig port on it, so we added a gig nic
to the head node and we sped up the dispatch like 7x, as I recall.

Of course I could be totally wrong, but this was something that I had
considered when working on a pvm-based cluster volume rendering project.

        -Dean