Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

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.

From: George Bosilca (bosilca_at_[hidden])
Date: 2007-05-29 11:23:05

I'd be happy to commit the patch into the trunk. But after what
happened last time, I'm more than cautious. If the community think
the patch is worth having it, let me know and I'll push it in the
trunk asap.


On May 29, 2007, at 10:56 AM, Tim Prins wrote:

> I think both patches should be put in immediately. I have done some
> simple testing, and with 128 nodes of odin, with 1024 processes
> running mpi hello, these decrease our running time from about 14.2
> seconds to 10.9 seconds. This is a significant decrease, and as the
> scale increases there should be increasing benefit.
> I'd be happy to commit these changes if no one objects.
> Tim
> On May 24, 2007, at 8:39 AM, Ralph H Castain wrote:
>> Thanks - I'll take a look at this (and the prior ones!) in the next
>> couple
>> of weeks when time permits and get back to you.
>> Ralph
>> On 5/23/07 1:11 PM, "George Bosilca" <bosilca_at_[hidden]> wrote:
>>> Attached is another patch to the ORTE layer, more specifically the
>>> replica. The idea is to decrease the number of strcmp by using a
>>> small hash function before doing the strcmp. The hask key for each
>>> registry entry is computed when it is added to the registry. When
>>> we're doing a query, instead of comparing the 2 strings we first
>>> check if the hash key match, and if they do match then we compare
>>> the
>>> 2 strings in order to make sure we eliminate collisions from our
>>> answers.
>>> There is some benefit in terms of performance. It's hardly visible
>>> for few processes, but it start showing up when the number of
>>> processes increase. In fact the number of strcmp in the trace file
>>> drastically decrease. The main reason it works well, is because most
>>> of the keys start with basically the same chars (such as orte-
>>> blahblah) which transform the strcmp on a loop over few chars.
>>> Ralph, please consider it for inclusion on the ORTE layer.
>>> Thanks,
>>> george.
>>> _______________________________________________
>>> devel mailing list
>>> devel_at_[hidden]
>> _______________________________________________
>> devel mailing list
>> devel_at_[hidden]
> _______________________________________________
> devel mailing list
> devel_at_[hidden]

  • application/pkcs7-signature attachment: smime.p7s