2010-05-02 8 views
5

MPI를 사용하여 하나의 C 구조체를 전송하는 데 필요한 코드 줄이 얼마나 많은지 나는 상당히 충격을 받았습니다.MPI와 C 구조체

미리 정의 된 데이터 유형 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); 

필자의 경우 모든 프로세스는 동일한 아키텍처에서 실행됩니다. 유일한 문제는 패딩입니까?

+1

MPI가 엄격한 요구 사항이 아니라면 Google의 프로토콜 버퍼를 사용하는 경우이 기회를 빌어서 말씀 드리고자합니다. http://code.google.com/apis/protocolbuffers/ – Stephen

+0

패딩에 대해 걱정하지 않아야합니다. 크기가 – Anycorn

+1

인 패딩을 포함하여 올바른 값을보고하지만 아키텍처에 따라 다를 수 있습니다. – hanno

답변

8

MPI_BYTE은 형식이 지정되지 않은 데이터를 보낼 때 사용하는 데이터 형식이며 MPI_CHAR이 아닙니다. 두 시스템이 동일한 아키텍처이지만 다른 문자 인코딩을 사용하는 경우 MPI_CHAR을 사용하면 데이터가 손상 될 수 있습니다. 데이터를 MPI_BYTE으로 보내면 이진 표현을있는 그대로 그대로두고 표현 변환을 전혀 수행하지 않습니다.

그렇습니다. 기술적으로 말해서, 데이터 표현이 송수신 끝에서 동일하다는 것을 보장 할 수 있다면, 구조적으로 그렇게하는 것이 옳습니다. 그러나 코드 목적을 이해하기 어렵고 플랫폼 종속성을 도입하기 때문에 프로그래밍 방식이 좋지 않습니다.

일반적으로 한 번만 데이터 유형을 정의하고 커밋해야하지만 일반적으로 여러 번 보내려면 코드를 작성해야합니다. 단일 정의에 몇 줄을 저장하기 위해 모든 전송자의 선명도를 줄이는 것이 트레이드 업이 아닙니다.

+0

감사합니다. 또 하나의 질문 : 'MPI_BYTE'를 사용하면 성능상의 이점이 있습니까? 또는, 내 자신의 MPI 데이터 형식으로 구조체를 전송할 때 오버 헤드가 있습니까? MPI가 작은 덩어리로 다른 버퍼에 데이터를 복사하는 것과 같은 것을 생각하고 있습니다. – hanno

+0

이것은 구현에 따라 달라질 수 있으며 표현 성능 검사/변환을 수행하지 않음으로써 얻을 수있는 성능 향상이 엄청나게 크다고 생각합니다. 처음부터 메시지를 전달하는 데 드는 전체 비용으로 인해 희미합니다. 아직도 형식이없는 vs 유형이없는 대형 페이로드 (수천 가지) 구조체를 보내는 데 걸리는 시간을 비교하는 흥미로운 실험이 될 수 있습니다. – suszterpatt

3

개인적으로 필자는 개인적으로 패딩보다 이해하기 쉽고 유지 보수성, 심지어 이식성에 더 관심이 있습니다. 구조체를 보내는 경우 구조체를 보내고 바이트 또는 문자 시퀀스가 ​​아니라는 것을 나타내는 코드가 마음에 든다. 또한 여러 세대의 언어 표준 및 컴파일러에서 여러 가지 아키텍처로 코드가 실행되기를 기대합니다.

구조체를 정의하는 것이 가치있는 경우 (그리고 분명히 생각한다고 생각하면) 구조체를 정의 할 가치가 있습니다. 몇 줄의 (거의) 상용구를 저장하는 것은 그다지 논쟁 거리가 아닙니다.

+1

나는 인수를 이해하지 못합니다. 유지 보수 가능성. 위의 코드 세그먼트에서, 다른 것을 할 필요없이 struct를 변경할 수 있습니다. 반면에 내가'MPI_Type_create_struct'를 사용하여 적절한 방법을 사용한다면 적어도 4 줄의 코드를 변경해야합니다 ... – hanno

+0

@hanno, @ suszterpatt의 유지 보수에 대한 논점에 대한 대답을 참조하십시오. –