특별한 선호 순서가없는 나의 목록. 인터페이스는 다음과 같아야합니다.
- 의존성이없는
<mpi.h>표준 헤더 및 표준 라이브러리
- 일반적이고 확장 가능해야합니다.
- 비 차단 만 가능 ( 차단 하려는 경우 기본적으로 명시 적이 아닌 명시 적으로 차단)
- 비 차단 작업의 연속 기반 체인을 허용합니다.
- 확장 가능하고 효율적인 직렬화 (Boost.Fusion과 같은 RMA와 함께 작동) 지원
- 추상화 불이익이 없습니다 (즉, C 인터페이스만큼 빠름).
- 안전해야합니다 (준비되지 않은 미래의 소멸자는?-> std :: terminate!).,
DEBUG수많은 명제를 가진 강력한 모드- 매우 유형 안전합니다 (더 이상 int / void *가 없으며 태그를 유형으로 만들고 싶습니다!),
- 람다와 함께 작동해야합니다 (예 : 모두 reduce + lambda).
- 오류보고 및 오류 처리 메커니즘으로 예외를 일관되게 사용합니다 (더 이상 오류 코드가 없으며 더 이상 함수 출력 인수가 없음).
- MPI-IO는 Boost.AFIO 스타일의 비 차단 I / O 인터페이스를 제공해야합니다.
- 그리고 현대적인 C ++ 인터페이스 디자인 관행을 따르십시오 (정규 유형 정의, 비회원 비 친구 기능, 이동 의미론과 잘 작동, 범위 작업 지원 ...)
추가 사항 :
MPI 환경의 실행 프로그램, 즉 사용하는 스레드 풀을 선택할 수 있습니다. 지금은 OpenMP, MPI, CUDA 및 TBB가 혼합 된 응용 프로그램을 동시에 실행할 수 있습니다. 각 런타임은 환경을 소유한다고 생각하여 운영 체제에 느낌이들 때마다 스레드를 요청합니다. 그것. 진심이야?
STL (및 Boost) 명명 규칙을 사용하십시오. 왜? 모든 C ++ 프로그래머는 그것을 알고 있습니다.
다음과 같은 코드를 작성하고 싶습니다.
auto buffer = some_t{no_ranks};
auto future = gather(comm, root(comm), my_offsets, buffer)
.then([&](){
/* when the gather is finished, this lambda will
execute at the root node, and perform an expensive operation
there asynchronously (compute data required for load
redistribution) whose result is broadcasted to the rest
of the communicator */
return broadcast(comm, root(comm), buffer);
}).then([&]() {
/* when broadcast is finished, this lambda executes
on all processes in the communicator, performing an expensive
operation asynchronously (redistribute the load,
maybe using non-blocking point-to-point communication) */
return do_something_with(buffer);
}).then([&](auto result) {
/* finally perform a reduction on the result to check
everything went fine */
return all_reduce(comm, root(comm), result,
[](auto acc, auto v) { return acc && v; });
}).then([&](auto result) {
/* check the result at every process */
if (result) { return; /* we are done */ }
else {
root_only([](){ write_some_error_log(); });
throw some_exception;
}
});
/* Here nothing has happened yet! */
/* ... lots and lots of unrelated code that can execute concurrently
and overlaps with communication ... */
/* When we now call future.get() we will block
on the whole chain (which might have finished by then!).
*/
future.get();
MPI_C를 사용하여이 모든 작업을 어떻게 연결할 수 있는지 생각해보십시오 request. 여러 관련되지 않은 코드를 통해 여러 (또는 모든 단일) 중간 단계에서 테스트하여 차단하지 않고 체인 을 진행할 수 있는지 확인해야합니다 .
