This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
There are several studies about compressions and data exchange. Few
years ago we integrate such mechanism (adaptive compression of
communication) in one of the projects here at ICL (called GridSolve).
The idea was to optimize the network traffic for sending large
matrices used for computation from a server to a specific workers.
Under some circumstances (few) it can improve the network traffic, and
according to the main author in the worst case it doesn't harm.
However, it is still unclear that there is any benefit when the data
is reasonably small (which is the case in ORTE).
The project is hosted at http://www.loria.fr/~ejeannot/adoc/adoc.html.
It's a simple dropin for read/write so it is fairly simple to
integrate. On the author webpage you can find some publication about
this, publication that highlight the performances of this approach.
PS: One of these a reference to the paper is available on ACM:
E. Jeannot, B. Knutsson, M. Bjorkmann.
Adaptive Online Data Compression, in: High Performance Distributed
Computing (HPDC'11), Edinburgh, Scotland, IEEE, july 2002.
On Apr 4, 2008, at 12:52 PM, Ralph H Castain wrote:
> Hello all
> Based on some discussion on this list, I integrated a zlib-based
> ability into ORTE. Since the launch message sent to the orteds and
> the modex
> between the application procs are the only places where messages of
> any size
> are sent, I only implemented compression for those two exchanges.
> I have found virtually no benefit to the compression. Essentially, the
> overhead consumed in compression/decompressing the messages pretty
> balances out any transmission time differences. However, I could
> only test
> this for 64 nodes, 8ppn, so perhaps there is some benefit at larger
> Even though my test size wasn't very big, I did try forcing the
> scenario. I included all available BTL's, and ran the OOB over
> Although there was some difference, it wasn't appreciable - easily
> the variations I see on this rather unstable machine.
> I invite you to try it yourself. You can get a copy of the code via:
> hg clone http://www.open-mpi.org/hg/hgwebdir.cgi/rhc/gather
> You will need to configure with LIBS=-lz.
> Compression is normally turned "off". You can turn it on by setting:
> -mca orte_compress 1
> You can also adjust the level of compression:
> -mca orte_compress_level [1-9]
> If you don't specify the level and select compression, the level will
> default to 1. From my tests, this seemed a good compromise. The
> other levels
> provided some small amount of better compression, but took longer.
> With compression "on", you will get output telling you the original
> size of
> the message and its compressed size so you can see what was done.
> Please let me know what you find out. I would like to reach a
> decision as to
> whether or not compression is worthwhile.
> devel mailing list
- application/pkcs7-signature attachment: smime.p7s