I would just caution against using Open MPI with a thread-enabled libevent. In most cases, the performance impact wouldn't matter, but the whole point of MPI is to be high performance. The current 1.7 series does *not* use a thread-enabled libevent because it detracts from performance. Hence, using a thread-enabled libevent detracts from Open MPI's main purpose.
If Open MPI is suddenly bundled with a thread-enabled libevent, *performance will go down* and users will be unhappy. We have learned painfully over the years that users expect good performance out of the box -- if they have get "bad" performance out of the box and have to do something special to enable "good" performance, they'll be annoyed and blame Open MPI.
So I would request that you do *not* link Open MPI against a thread-enabled libevent until we are able integrate such functionality properly, and take measures to mitigate the performance implications (which likely won't be until at least the 1.9 series).
On Apr 23, 2013, at 6:30 PM, Ralph Castain <rhc_at_[hidden]> wrote:
> On Apr 23, 2013, at 3:23 PM, Orion Poplawski <orion_at_[hidden]> wrote:
>> On 04/17/2013 03:40 PM, Ralph Castain wrote:
>>> On Apr 17, 2013, at 1:19 PM, Orion Poplawski <orion_at_[hidden]> wrote:
>>>>>> So other than openmpi expecting to work with a specific version of libevent, I'm not seeing compelling reason why bundling is necessary (at least for Fedora packaging). If there is, please let me know.
>>>>> I'd hate to make a Fedora-specific change and then have users complain because of things like performance degradation on that platform. As Jeff pointed out, this is how we've distributed OMPI on every platform since day one - I'm not hearing a compelling reason to change that policy. We'd have to discuss any such request at our next weekly meeting (Tues mornings).
>>>> Of course.
>>> You've raised a good question - I'll bring it up at the next meeting and see what people think.
>> Anything to report? Thanks!
> Yes - we discussed it and will look into the possibility of supporting an external libevent in the future. May take awhile for us to get around to it, though, and cannot guarantee that we can do it - but we will see if it can be done.
>> Orion Poplawski
>> Technical Manager 303-415-9701 x222
>> NWRA, Boulder/CoRA Office FAX: 303-415-9702
>> 3380 Mitchell Lane orion_at_[hidden]
>> Boulder, CO 80301 http://www.nwra.com
>> devel mailing list
> devel mailing list
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/