MPI и C-структуры

Должен признаться, я был весьма шокирован, увидев, сколько строк кода требуется для передачи одной структуры 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);

В моем случае все процессы работают на одной архитектуре. Является ли прокладка единственной проблемой?


c struct mpi
person hanno    schedule 02.05.2010    source источник
comment
Я хотел бы воспользоваться этой возможностью, чтобы сказать, что если MPI не является строгим требованием, используйте буферы протокола Google. code.google.com/apis/protocolbuffers   -  person Stephen    schedule 02.05.2010
comment
вам не следует беспокоиться о заполнении, sizeof сообщает правильное значение, включая дополнение   -  person Anycorn    schedule 02.05.2010
comment
да, но это может варьироваться в зависимости от архитектуры...   -  person hanno    schedule 03.05.2010

Ответы (2)


arrow_upward
8
arrow_downward

MPI_BYTE — это тип данных, который следует использовать при отправке нетипизированных данных, а не MPI_CHAR. Если две машины имеют одинаковую архитектуру, но используют разную кодировку символов, использование MPI_CHAR может привести к повреждению ваших данных. Отправка ваших данных как MPI_BYTE оставит двоичное представление без изменений и не будет выполнять никакого преобразования представления.

Тем не менее, да, технически правильно отправлять структуру таким образом, если (и только если) вы можете гарантировать, что представление данных будет одинаковым на отправляющей и принимающей сторонах. Однако это плохая практика программирования, поскольку она запутывает цель вашего кода и вводит зависимость от платформы.

Имейте в виду, что вам нужно определить и зафиксировать тип данных только один раз, в то время как вам, как правило, потребуется написать код для его отправки несколько раз. Уменьшение четкости всех ваших посылов только для того, чтобы сэкономить пару строк в одном разрешении — это не компромисс.

person suszterpatt    schedule 04.05.2010
comment
Спасибо. Еще один вопрос: есть ли выигрыш в производительности от использования MPI_BYTE? Или есть ли какие-либо накладные расходы, когда я передаю структуру с моим собственным типом данных MPI? Я думаю о чем-то вроде MPI, копирующего данные в другой буфер небольшими порциями и т. Д. - person hanno; 04.05.2010
comment
Это, вероятно, зависит от реализации, и я полагаю, что любой прирост производительности, который вы получите от невыполнения проверки/преобразования представления, в первую очередь будет омрачен общей стоимостью передачи сообщения. Тем не менее, может быть интересным экспериментом сравнить, сколько времени требуется для отправки большой полезной нагрузки (тысячи) типизированных и нетипизированных структур. - person suszterpatt; 07.05.2010

arrow_upward
3
arrow_downward

Лично меня больше заботит понятность и ремонтопригодность, даже переносимость, чем заполнение. Если я отправляю структуру, мне нравится, когда мой код показывает, что я отправляю структуру, а не последовательность байтов или символов. И я ожидаю, что мои коды будут работать на нескольких архитектурах, на нескольких поколениях языковых стандартов и компиляторов.

Я думаю, все, что я хочу сказать, это то, что если стоит определять структуру (а вы, очевидно, так и думаете), то стоит определять структуру. Сохранение нескольких строк (почти) шаблона не является большим аргументом против этого.

person High Performance Mark    schedule 02.05.2010
comment
Я не понимаю спора о ремонтопригодности. В приведенном выше сегменте кода я могу изменить структуру без необходимости делать что-либо еще. В то время как, если я сделаю это правильно, используя MPI_Type_create_struct, мне придется изменить как минимум 4 строки кода... - person hanno; 02.05.2010
comment
@hanno, см. ответ @suszterpatt на аргумент о ремонтопригодности, объясненный лучше, чем мне удалось. - person High Performance Mark; 04.05.2010