George,
Thank you a lot. It makes more sense now.
Best regards,
Khalid
On Thu, May 21, 2015 at 4:14 AM, George Bosilca wrote:
> Khalid,
>
> The rule number zero is always selected by default. If the size you look
> for (message or communicator) is larger than zero then another rule will be
> s
Khalid,
The rule number zero is always selected by default. If the size you look
for (message or communicator) is larger than zero then another rule will be
selected, otherwise zero is the best selection. Same thing for communicator
and size, a consistent approach from my perspective.
If you don'
George,
Thank you for your answer.
Another confusing thing is that, If I use some communicator size which does
not exist in the configuration file, some rule from the configuration file
will be used anyway.
For example, let say I have a configuration file with two communicator
sizes 5 and 16. If
Khalid,
The way we designed these rules was to define intervals in a 2 dimension
space (communicator size, message size). You should imagine these rules as
exclusive, you match them in the order defined by the configuration file
and you use the algorithm defined by the last matching rule.
Georg
Thanks a lot, Gilles.
On Wed, May 20, 2015 at 2:47 AM, Gilles Gouaillardet
wrote:
> Khalid,
>
> this is probably not the intended behavior, i will followup on the devel
> mailing list.
>
> Thanks for reporting this
>
> Cheers,
>
> Gilles
>
>
> On 5/20/2015 10:30 AM, Khalid Hasanov wrote:
>
> Hi
Khalid,
this is probably not the intended behavior, i will followup on the devel
mailing list.
Thanks for reporting this
Cheers,
Gilles
On 5/20/2015 10:30 AM, Khalid Hasanov wrote:
Hi Gilles,
Thank you a lot, it works now.
Just one minor thing I have seen now. If I use some communicator
Hi Gilles,
Thank you a lot, it works now.
Just one minor thing I have seen now. If I use some communicator size which
does not exist in the configuration file, it will still use the
configuration file. For example, if I use the previous config file with
mpirun -n 4 it will use the config for the
Hi Khalid,
i checked the source code and it turns out rules must be ordered :
- first by communicator size
- second by message size
Here is attached an updated version of the ompi_tuned_file.conf you
should use
Cheers,
Gilles
On 5/20/2015 8:39 AM, Khalid Hasanov wrote:
Hello,
I am trying t
George and Gilles, thank you for your answers.
@George, honestly I didn't know that the decision is rechecked for every
new communicator creation operation. I will try it. In fact we used
sub-communicators for some other research work previously and indeed it
outweigh the benefits for small mess
Khalid,
The decision is rechecked every time we create a new communicator. So, you
might create a solution that force the algorithm to whatever you think it is
best (using the environment variables you mentioned), then create a
communicator, and free it once you’re done.
I have no idea what yo
Khalid,
i am not aware of such a mechanism.
/* there might be a way to use MPI_T_* mechanisms to force the algorithm,
and i will let other folks comment on that */
you definetly cannot directly invoke ompi_coll_tuned_bcast_intra_binomial
(abstraction violation, non portable, and you miss the som
11 matches
Mail list logo
