On Aug 16, 2009, at 8:16 PM, Eugene Loh wrote:
Chris Samuel wrote:
- "Eugene Loh" wrote:
This is an important discussion.
Indeed! My big fear is that people won't pick up the significance
of the change and will complain about performance regressions
in the middle of an OMPI stable re
Chris Samuel wrote:
- "Eugene Loh" wrote:
This is an important discussion.
Indeed! My big fear is that people won't pick up the significance
of the change and will complain about performance regressions
in the middle of an OMPI stable release cycle.
2) The pro
- "Eugene Loh" wrote:
> This is an important discussion.
Indeed! My big fear is that people won't pick up the significance
of the change and will complain about performance regressions
in the middle of an OMPI stable release cycle.
> Do note:
>
> 1) Bind-to-core is actually the default be
I tend to agree with Chris. Changing the behavior of the 1.3 in the
middle of the stable release cycle, will be very confusing for our
users. Moreover, as Ralph pointed out, everything in Open MPI is
configurable so if we advertise this feature in the Changelog, the
institutions where the n
- "Ralph Castain" wrote:
> Hi Chris
Hiya Ralph,
> There would be a "-do-not-bind" option that will prevent us from
> binding processes to anything which should cover that situation.
Gotcha.
> My point was only that we would be changing the out-of-the-box
> behavior to the opposite of tod
A question about library dependencies in the ompi build system. I am creating
a new ompi component that has uses routines out of ompi/common/a and
ompi/common/b . How do I get routines from ompi/common/a to pick up the
symbols in ompi/common/b ? The symbol I am after is clearly in
libmca_com
This is an important discussion. Do note:
1) Bind-to-core is actually the default behavior of many MPIs today.
2) The proposed OMPI bind-to-socket default is less severe. In the
general case, it would allow multiple jobs to bind in the same way
without oversubscribing any core or socket. (
Hi Chris
There would be a "-do-not-bind" option that will prevent us from binding
processes to anything which should cover that situation.
My point was only that we would be changing the out-of-the-box behavior to
the opposite of today's, so all those such as yourself would now have to add
the -d
- "Terry Dontje" wrote:
> I just wanted to give everyone a heads up if they do not get bugs
> email. I just submitted a CMR to move over some new paffinity options
> from the trunk to the v1.3 branch.
Ralphs comments imply that for those sites that share nodes
between jobs (such as oursel
