On 4/7/08 7:45 AM, "Gleb Natapov" wrote:
> On Mon, Apr 07, 2008 at 07:28:07AM -0600, Ralph H Castain wrote:
>>> Also can you explain how
>>> allgather is implemented in orte (sorry if you already explained this once
>>> and I missed it).
>>
>> The default method is for
On Mon, Apr 07, 2008 at 07:28:07AM -0600, Ralph H Castain wrote:
> > Also can you explain how
> > allgather is implemented in orte (sorry if you already explained this once
> > and I missed it).
>
> The default method is for each proc to send its modex data to its local
> daemon. The local daemon
On 4/7/08 7:15 AM, "Gleb Natapov" wrote:
> On Mon, Apr 07, 2008 at 07:07:38AM -0600, Ralph H Castain wrote:
>>
>>
>>
>> On 4/7/08 7:04 AM, "Gleb Natapov" wrote:
>>
>>> On Fri, Apr 04, 2008 at 10:52:38AM -0600, Ralph H Castain wrote:
With
On Mon, Apr 07, 2008 at 07:07:38AM -0600, Ralph H Castain wrote:
>
>
>
> On 4/7/08 7:04 AM, "Gleb Natapov" wrote:
>
> > On Fri, Apr 04, 2008 at 10:52:38AM -0600, Ralph H Castain wrote:
> >> With compression "on", you will get output telling you the original size of
> >>
actually, we used lzo a looong time ago with PACX-MPI, it was indeed
faster then zlib. Our findings at that time were however similar to what
George mentioned, namely a benefit from compression was only visible if
the network latency was really high (e.g. multiple ms)...
Thanks
Edgar
Roland
LZO looks cool, but it's unfortunately GPL (Open MPI is BSD). Bummer.
On Apr 4, 2008, at 2:29 PM, Roland Dreier wrote:
Based on some discussion on this list, I integrated a zlib-based
compression
ability into ORTE. Since the launch message sent to the orteds and
the modex
between the
> Based on some discussion on this list, I integrated a zlib-based compression
> 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
Ralph,
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