You are right, during the reading of the configuration file we are bailing
out if a rule doesn't start with a zero-length. While the selection logic
(where I was looking) doesn't have such a restriction (it automatically
selects the first rule), I consider that forcing the communicator-based
rules
George,
i understand the logic (even if i still find it counter intuitive, but this
is an other story)
if a rule for zero-sized messages is not needed, then there is a bug ...
if (!nms && MS) {
OPAL_OUTPUT((ompi_coll_tuned_stream,"All algorithms
must specify a
Gilles,
There is no need to define a rule for zero-sized messages, it is implicitly
matched by the first rule. To be extremely pedantic the selection logic for
the communicator size and message size are identical albeit written
differently. Both start by selecting rule 0, and then working their wa
George,
first i'd like to amend my initial message.
i previously wrote the same algo is used to parse rules per communicator
size and per message size.
this is true, but i missed the part where it is mandatory to define a
rule for zero size message.
consequently, a given message is either in an
Each rule define an interval with the previous rule, and everything in an
interval will be bound the the rule with the next message size. You cannot
define a rule for a specific amount. Thus, the fact that the rules must be
ordered by message size was done by design.
Returning a NULL rule as sugge
I could be wrong (George, please feel free to correct me), but I *think*
this was the designed behavior. If you read Jelena's paper,
http://www.open-mpi.org/papers/euro-pvmmpi-2006-collective-alg-selection/euro-pvmmpi-2006-collective-alg-selection.pdf
you basically construct a new decision map
Howard,
i made PR 593 https://github.com/open-mpi/ompi/pull/593 in order to fix
this.
George,
could you please review this ?
Cheers,
Gilles
On 5/20/2015 12:57 PM, Howard Pritchard wrote:
HI Gilles,
First a disclaimer - I do not know what the intended design was nor
where the design docu
HI Gilles,
First a disclaimer - I do not know what the intended design was nor where
the design document
for this feature is located.
However, I would certainly prefer that if the communicator size wasn't
specifically specified
in the rule file, a fall back do-no-harm algorithm would be selected.
Folks,
this is a follow-up of a discussion on the user ML started at
http://www.open-mpi.org/community/lists/users/2015/05/26882.php
1) it turns out the dynamic rule filename must be "sorted" :
- rules must be sorted by communicator size
- within a given communicator size, rules must be sorted
