Народ, подскажите, какая логика стоит за тем, чтобы использовать одну и ту же функцию и для отсылки, и для сбора данных от процессов? Я имею в виду MPI_Gather.
Заечм делать
int MPI_Gather(void* sendbuf, //IN адрес начала размещения посылаемых данных;
int sendcount, //IN число посылаемых элементов;
MPI_Datatype sendtype, //IN тип посылаемых элементов;
void* recvbuf, //OUT адрес начала буфера приема (используется только в процессе-получателе root);
int recvcount, //IN число элементов, получаемых от каждого процесса (используется только в процессе-получателе root);
MPI_Datatype recvtype, //IN тип получаемых элементов;
int root, //IN номер процесса-получателя;
MPI_Comm comm) //IN коммуникатор.
заставляя всовывать неиспользующиеся аргументы в функцию?
Здравствуйте, _hum_, Вы писали:
__>Народ, подскажите, какая логика стоит за тем, чтобы использовать одну и ту же функцию и для отсылки, и для сбора данных от процессов? Я имею в виду MPI_Gather.
__>Заечм делать
__>__> int MPI_Gather(void* sendbuf, //IN адрес начала размещения посылаемых данных;
__> int sendcount, //IN число посылаемых элементов;
__> MPI_Datatype sendtype, //IN тип посылаемых элементов;
__> void* recvbuf, //OUT адрес начала буфера приема (используется только в процессе-получателе root);
__> int recvcount, //IN число элементов, получаемых от каждого процесса (используется только в процессе-получателе root);
__> MPI_Datatype recvtype, //IN тип получаемых элементов;
__> int root, //IN номер процесса-получателя;
__> MPI_Comm comm) //IN коммуникатор.
__>
__>заставляя всовывать неиспользующиеся аргументы в функцию?
Предполагаю, что так просто короче и удобнее, а "красота" или "логика" принесена в жертву. Такие вспомогательные функции всегда можно заменить алгоритмом на основе MPI_Send/MPI_Recv, но, когда начинаешь писать этот алгоритм, понимаешь, что начинаешь изобретать велосипед.
Здравствуйте, Андрюха, Вы писали:
А>Здравствуйте, _hum_, Вы писали:
__>>Народ, подскажите, какая логика стоит за тем, чтобы использовать одну и ту же функцию и для отсылки, и для сбора данных от процессов? Я имею в виду MPI_Gather.
__>>Заечм делать
__>>__>> int MPI_Gather(void* sendbuf, //IN адрес начала размещения посылаемых данных;
__>> int sendcount, //IN число посылаемых элементов;
__>> MPI_Datatype sendtype, //IN тип посылаемых элементов;
__>> void* recvbuf, //OUT адрес начала буфера приема (используется только в процессе-получателе root);
__>> int recvcount, //IN число элементов, получаемых от каждого процесса (используется только в процессе-получателе root);
__>> MPI_Datatype recvtype, //IN тип получаемых элементов;
__>> int root, //IN номер процесса-получателя;
__>> MPI_Comm comm) //IN коммуникатор.
__>>
__>>заставляя всовывать неиспользующиеся аргументы в функцию?
А>Предполагаю, что так просто короче и удобнее, а "красота" или "логика" принесена в жертву. Такие вспомогательные функции всегда можно заменить алгоритмом на основе MPI_Send/MPI_Recv, но, когда начинаешь писать этот алгоритм, понимаешь, что начинаешь изобретать велосипед.
ммм...с каких пор "короче" стало приоритетнее при написании прог, чем "понятнее"? мне, например, не очень нравится, что вместо того, чтобы писать что-то наподобие
if(0 == proc_rank)
{
std::vector<int> MPIGatheredValues(nMPIProcessesCount, 0);
MPI_Gather(MPIGatheredValues.data(), 1, MPI_INT, 0, MPI_COMM_WORLD);
//<working as for a root process>
}
else
{
const int value = <something>;
MPI_SendForGathering(&value, 1, MPI_INT, 0, MPI_COMM_WORLD);
//<working as for a non root process>
}
приходится мешать все в кучу, наподобие
std::vector<int> MPIGatheredValues(nMPIProcessesCount, 0);
const int value = <something>;
MPI_Gather(&value, 1, MPI_INT, MPIGatheredValues.data(), 1, MPI_INT, 0, MPI_COMM_WORLD);
UPD. Возникла мысль — может быть, так сделано, для того, чтобы гарантировать, что всегда будет отсылающий и собирающий?
Здравствуйте, _hum_, Вы писали:
__>ммм...с каких пор "короче" стало приоритетнее при написании прог, чем "понятнее"? мне, например, не очень нравится, что вместо того, чтобы писать что-то наподобие
__>__>if(0 == proc_rank)
__>{
__> std::vector<int> MPIGatheredValues(nMPIProcessesCount, 0);
__> MPI_Gather(MPIGatheredValues.data(), 1, MPI_INT, 0, MPI_COMM_WORLD);
__> //<working as for a root process>
__>}
__>else
__>{
__> const int value = <something>;
__> MPI_SendForGathering(&value, 1, MPI_INT, 0, MPI_COMM_WORLD);
__> //<working as for a non root process>
__>}
__>
Если не нравится, то реализуйте свои версии MPI_Gather и MPI_SendForGathering, и работайте с ними. В чем проблема?
Будет у вас хорошая обертка, люди начнут пользоваться ею.
__>приходится мешать все в кучу, наподобие
__>__>std::vector<int> MPIGatheredValues(nMPIProcessesCount, 0);
__>const int value = <something>;
__>MPI_Gather(&value, 1, MPI_INT, MPIGatheredValues.data(), 1, MPI_INT, 0, MPI_COMM_WORLD);
__>
Это непривычно поначалу, но мне особых проблем не доставляет. К тому же, второй вариант выглядит компактней и понятней. Ветвления воспринимаются сложнее.
Все-таки MPI — это дитя научного сообщества, а не программистов, так что тут могут быть немного другие приоритеты.
__>UPD. Возникла мысль — может быть, так сделано, для того, чтобы гарантировать, что всегда будет отсылающий и собирающий?
Программист гарантирует наличие отправителя и получателя, функции сами по себе этого сделать не могут.
Здравствуйте, Андрюха, Вы писали:
А>Если не нравится, то реализуйте свои версии MPI_Gather и MPI_SendForGathering, и работайте с ними. В чем проблема?
А>Будет у вас хорошая обертка, люди начнут пользоваться ею.
вопрос был, почему сделали так, как сделали — часто в таких ситуациях есть какие-то подводные камни, которые "неестественная" на первый взгляд реализация и пытается обойти.
__>>приходится мешать все в кучу, наподобие
__>>__>>std::vector<int> MPIGatheredValues(nMPIProcessesCount, 0);
__>>const int value = <something>;
__>>MPI_Gather(&value, 1, MPI_INT, MPIGatheredValues.data(), 1, MPI_INT, 0, MPI_COMM_WORLD);
__>>
А>Это непривычно поначалу, но мне особых проблем не доставляет. К тому же, второй вариант выглядит компактней и понятней. Ветвления воспринимаются сложнее.
А>Все-таки MPI — это дитя научного сообщества, а не программистов, так что тут могут быть немного другие приоритеты.
ну так тут ветвление тоже есть, токо оно спрятано внутри MPI_Gather. получается, один и тот же код в разных процессах имеет разную семантику, что, имхо, не есть гуд.
__>>UPD. Возникла мысль — может быть, так сделано, для того, чтобы гарантировать, что всегда будет отсылающий и собирающий?
А>Программист гарантирует наличие отправителя и получателя, функции сами по себе этого сделать не могут.
еще как могут — если функция такова, что ее нельзя написать без отправителя и получателя, то можно говорить, что она гарантирет наличие того и другого
