Использование protobuf с MPI для нового типа данных? - PullRequest
Новая
       8

Использование protobuf с MPI для нового типа данных?

0 голосов
/ 08 сентября 2018

Как правило, нужно было бы определить новый тип и зарегистрировать его в MPI, чтобы использовать его. Мне интересно, если использовать protobuf для сериализации объекта и отправить его с использованием MPI в качестве потока байтов. У меня есть два вопроса: (1) вы предвидите какие-либо проблемы с этим подходом? (2) мне нужно отправить информацию о длине через отдельный MPI_Send(), или я могу исследовать и использовать MPI_Get_count(&status, MPI_BYTE, &count)?

Примером может быть: 

        // sender 
        MyObj myobj; 
        ...
        size_t size = myobj.ByteSizeLong();
        void *buf = malloc(size);
        myobj.SerializePartialToArray(buf, size);
        MPI_Isend(buf, size, MPI_BYTE, ... )
        ...

        // receiver
        MPI_Iprobe(MPI_ANY_SOURCE, MPI_ANY_TAG, MPI_COMM_WORLD, &flag, &status);
        if (flag) {
            MPI_Get_count(&status, MPI_BYTE, &size);
            MPI_Recv(buf, size, MPI_BYTE, ... , &status);
            MyObject obj;
            obj.ParseFromArray(buf, size);
            ...

        }

1 Ответ

0 голосов
/ 08 сентября 2018

Как правило, вы можете сделать это. Эскиз кода также выглядит хорошо (за исключением пропущенного выделения buf на стороне получателя). Как указывает Жиль, обязательно используйте status.MPI_SOURCE и status.MPI_TAG для фактического MPI_Recv, а не MPI_*_ANY.

Однако существуют некоторые ограничения производительности.

  1. Protobuf не очень быстрый, особенно из-за кодирования / декодирования. Это очень сильно зависит от ваших ожиданий. Если вы работаете в высокопроизводительной сети, это может оказать значительное влияние. Вот некоторые основные тесты .

  2. Незнание размера сообщения впереди и, следовательно, постоянная публикация получения после отправки также влияет на производительность. Это означает, что фактическая передача, скорее всего, начнется позже, что может повлиять или не повлиять на отправителей, так как вы используете неблокирующие посылки. Могут быть случаи, когда вы сталкиваетесь с некоторыми практическими ограничениями в отношении количества неожиданных сообщений. Это не является общей проблемой правильности, но может потребовать некоторой настройки конфигурации.

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

...