2013-11-01 1 views
6

모델에 맞게 작은 행렬 (50-100 x 1000 요소)에서 몇 가지 MKL 호출을 수행하는 루틴을 가지고 있습니다. 그런 다음 다른 모델을 호출합니다. 의사 코드에서 :인텔 피의 MKL 성능

int main(int argc, char **argv) { 
    ... 
    int numthreads=omp_max_num_threads(); 
    int c; 
#pragma omp parallel for private(c) 
    for(int t=0; t<numthreads; t++) { 
    // assuming nmodel divisible by numthreads...  
    c_start = t*nmodel/numthreads+1; 
    c_end = (t+1)*nmodel/numthreads; 
    for(c=c_start; c<c_stop; c++) { 
     ... 
     result = doModelFit(c, ...); 
     ... 
    } 
    } 
} 

:

double doModelFit(int model, ...) { 
    ... 
    while(!done) { 
    cblas_dgemm(...); 
    cblas_dgemm(...); 
    ... 
    dgesv(...); 
    ... 
    } 
    return result; 
} 

int main(int argc, char **argv) { 
    ... 
    c_start = 1; c_stop = nmodel; 
    for(int c=c_start; c<c_stop; c++) { 
    ... 
    result = doModelFit(c, ...); 
    ... 
    } 
} 

전화 위의 버전 1 모델이 독립적이기 때문에, 나는 (버전 2) 다음과 같이 피팅 모델을 병렬화의 OpenMP 스레드를 사용할 수 있습니다 호스트 시스템에서 버전 1을 실행하면 ~ 11 초가 걸리며, VTune은 대부분의 시간이 유휴 상태 인 경우 불량 병렬 처리를보고합니다. 호스트 시스템의 버전 ​​2는 약 5 초가 걸리며, VTune은 훌륭한 병렬 처리를보고합니다 (사용중인 CPU 8 개를 사용하면 거의 100 %가 소비됩니다). 이제 Phi 카드를 기본 모드 (-mmic)로 실행하도록 컴파일하면 mic0의 명령 프롬프트에서 버전 1과 2가 모두 약 30 초가 걸립니다.

  • 버전 1은 동일한 약 30 초 정도 소요되며, 핫스팟 분석은 대부분의 시간을 __kmp_wait_sleep 및 __kmp_static_yield에 소요되는 것을 보여준다 : 나는의 VTune을 사용하는 경우를 프로파일합니다. 7710 초의 CPU 시간 중 5804 초가 스핀 시간에 소비됩니다.
  • 버전 2는 fooooorrrreevvvver를 필요로합니다. VTune에서 2 ~ 3 분 정도 실행 한 후 종료합니다. 핫스팟 분석 결과 CPU 시간이 25254s이고 [vmlinux]에서 21585s가 소비되었음을 알 수 있습니다.

여기에 무슨 일이 일어나고 있는지, 왜 그런 나쁜 성능을 얻었는지에 대해 알 수 있습니까? OMP_NUM_THREADS에 기본값을 사용하고 KMP_AFFINITY = compact, granularity = fine (Intel에서 권장하는대로)을 설정합니다. 나는 MKL과 OpenMP에 익숙하지 않아 신기한 실수를 저지르고 있다고 확신한다.

감사합니다, 앤드류

+1

MKL에는 Phi의 작은 행렬에 심각한 성능 문제가 있습니다. 인텔 포럼에서 질문을 게시하는 것이 좋습니다. http://software.intel.com/en-us/forums/intel-many-integrated-core – pburka

+1

@pburka 저도 게시했습니다. 그냥 더 넓은 그물을 던지려고. :) 작은 매트릭스 문제에 대한 링크가 있습니까? – Andrew

+1

여기에 문제가 하나 있습니다 : http://software.intel.com/en-us/forums/topic/475924. 나는 또한 프리미어 지원을 통해 인텔을 따르고있다. 이 경우 MKL은 스레드 수를 30으로 줄인 다음 GEMM 호출 후 스레드를 다시 돌리는 데 1ms가 걸린다 고 생각합니다. 그러나 나는 이것이 유일한 GEMM 성능 문제는 아니라고 생각한다. – pburka

답변

1

, 대부분의 시간은 OS (의 vmlinux)에 소요되는 주어진이 문제에 대한 가장 가능성이 높은 이유는 오버 서브 스크립 cblas_dgemm()dgesv의 MKL 구현 안에 중첩 OpenMP를 병렬 지역에 따라 발생 . 예 : this example을 참조하십시오.

이 버전은 Jim Dempsey가 Intel forum에서 지원하고 설명합니다.

0

MKL : 순차 라이브러리 사용은 어떻게됩니까? 순차 옵션과 함께 MKL 라이브러리를 연결하면 MKL 자체 내부에서 OpenMP 스레드가 생성되지 않습니다. 나는 당신이 지금보다 나은 결과를 얻을 것 같아요.

+0

이 질문에 대한 답변을 제공하지 않습니다. 비평하거나 저자의 설명을 요청하려면 게시물 아래에 의견을 남기십시오. 자신의 게시물에 언제나 댓글을 달 수 있으며 충분한 [평판] (http://stackoverflow.com/help/whats-reputation)을 갖게되면 [모든 게시물에 댓글을 달 수] 있어야합니다 (http://stackoverflow.com/help/privileges/comment). – durron597

+0

일반적으로 도구 또는 라이브러리에 대한 링크 또는 참조에는 권장 리소스가 문제에 어떻게 적용되는지에 대한 구체적인 설명이 포함되어서는 안되며 [사용법 메모 또는 샘플 코드가 함께 제공됩니다 (http : //meta.stackoverflow .com/a/251605). (@ durron597 : 기술적으로, 이것은 대답이다. 단지 그 놀라운 것 전부는 아니다.) –

관련 문제