Я должен признать, я был вполне потрясен видеть, сколько строк кода требуется, чтобы передавать одну структуру C с MPI.
При каких обстоятельствах будет он работать для простой передачи структуры с помощью предопределенного типа данных MPI_CHAR
? Рассмотрите следующий пример:
struct particle {
double x;
double y;
long i;
};
struct particle p;
MPI_Isend(&p, sizeof(particle), MPI_CHAR, tag, MPI_COMM_WORLD, &sendr);
В моем случае все процессы работают на той же архитектуре. Действительно ли дополнение является единственной проблемой?
MPI_BYTE
- это тип данных, который следует использовать при отправке нетипизированных данных, а не MPI_CHAR
. Если две машины имеют одинаковую архитектуру, но используют разную кодировку символов, использование MPI_CHAR
может повредить ваши данные. Отправка ваших данных как MPI_BYTE
оставит двоичное представление как есть и не выполнит никакого преобразования представления.
Тем не менее, да, технически правильно отправлять структуру таким образом, если (и только если) вы можете гарантировать, что представление данных будет одинаковым на отправляющем и принимающем концах. Однако это плохая практика программирования, поскольку она скрывает цель вашего кода и вводит зависимость от платформы.
Имейте в виду, что вам нужно определить и зафиксировать тип данных только один раз, в то время как обычно вам нужно писать код для его отправки несколько раз. Уменьшение четкости всех ваших посылов только для того, чтобы сэкономить пару строк на одном определении, не является компромиссом.
Лично меня больше беспокоит понятность и ремонтопригодность, даже переносимость, чем заполнение. Если я отправляю структуру, мне нравится, что мой код показывает, что я отправляю структуру, а не последовательность байтов или символов. И я ожидаю, что мои коды будут работать на нескольких архитектурах, на нескольких поколениях языковых стандартов и компиляторов.
Я думаю, все, что я говорю, это то, что если стоит определить структуру (а вы, очевидно, так думаете), то стоит определить структуру. Сохранение нескольких строк (почти) шаблона - не лучший аргумент против этого.