C 코드 루프 성능 [계속]


83

이 질문은 Mystical의 조언에 따라 여기 내 질문에 계속됩니다.

C 코드 루프 성능


내 질문에 계속해서 스칼라 명령어 대신 포장 명령어를 사용하면 내장 함수를 사용하는 코드가 매우 유사하게 보입니다.

for(int i=0; i<size; i+=16) {
    y1 = _mm_load_ps(output[i]);
    …
    y4 = _mm_load_ps(output[i+12]);

    for(k=0; k<ksize; k++){
        for(l=0; l<ksize; l++){
            w  = _mm_set_ps1(weight[i+k+l]);

            x1 = _mm_load_ps(input[i+k+l]);
            y1 = _mm_add_ps(y1,_mm_mul_ps(w,x1));
            …
            x4 = _mm_load_ps(input[i+k+l+12]);
            y4 = _mm_add_ps(y4,_mm_mul_ps(w,x4));
        }
    }
    _mm_store_ps(&output[i],y1);
    …
    _mm_store_ps(&output[i+12],y4);
    }

이 커널의 측정 된 성능은주기 당 약 5.6FP 작업이지만 스칼라 버전 성능의 정확히 4 배, 즉주기 당 4.1,6 = 6,4 FP 작업이 될 것으로 예상합니다.

가중치 요소의 이동을 고려하면 (이를 지적 해 주셔서 감사합니다) 일정은 다음과 같습니다.

시간표

movss스칼라 가중치 값을 XMM 레지스터로 이동 한 다음 shufps이 스칼라 값을 전체 벡터에 복사하는 데 사용 하는 작업 후에 추가 명령이 있지만 일정이 변경되지 않은 것처럼 보입니다 . 가중치 벡터는 mulps부하에서 부동 소수점 도메인으로의 전환 지연을 고려하여 당분간 사용할 준비가 된 것 같으 므로 추가 지연이 발생하지 않아야합니다.

movaps(정렬, 포장 이동), addpsmulps이 중 여분의 대기 시간이 발생해서는 안 (어셈블리 코드로 확인)이 커널에 사용되는 지침은, 자신의 스칼라 버전과 동일한 지연 시간 및 처리량을 가지고있다.

이 커널이 얻을 수있는 최대 성능이주기 당 6.4FP 작업이고주기 당 5.6FP 작업으로 실행되고 있다고 가정 할 때 8주기 당 추가주기가 어디에 사용되는지 아는 사람이 있습니까?


참고로 실제 어셈블리는 다음과 같습니다.

…
Block x: 
  movapsx  (%rax,%rcx,4), %xmm0
  movapsx  0x10(%rax,%rcx,4), %xmm1
  movapsx  0x20(%rax,%rcx,4), %xmm2
  movapsx  0x30(%rax,%rcx,4), %xmm3
  movssl  (%rdx,%rcx,4), %xmm4
  inc %rcx
  shufps $0x0, %xmm4, %xmm4               {fill weight vector}
  cmp $0x32, %rcx 
  mulps %xmm4, %xmm0 
  mulps %xmm4, %xmm1
  mulps %xmm4, %xmm2 
  mulps %xmm3, %xmm4
  addps %xmm0, %xmm5 
  addps %xmm1, %xmm6 
  addps %xmm2, %xmm7 
  addps %xmm4, %xmm8 
  jl 0x401ad6 <Block x> 
…

이제 질문은 "왜 shufps명령이 1.6 반복마다 1 사이클을 추가합니까?"입니다. 즉 ... 힘든 하나
Mysticial

난의 출력은 이후 더 오버 헤드가없는 기대 shufps직접 사용할 수 있어야 multps그것이 모두 FP 도메인이기 때문에 연산
리키

쉽게 찾을 수 있습니다. 가중치 벡터에 비정규 화 된 값 값이 포함되어 있지 않은지 확인하십시오. 셔플 명령없이 루프를 시도하십시오. 유용한 결과를 생성하지는 못하지만, 어떤 명령어가 추가주기를 필요로하는지 찾을 수 있습니다 (물론 셔플을 의심합니다).
Gunther Piez 2012

@Mystical : 루프 반복 당 0.75 사이클이 추가되었습니다. (그것은 :-) ...이 답변에 당신을 이끌 5 개주기 대신 사를 사용하는 방법에 대한 내 댓글 아니 었)
군터 Piez

3
우선, 이제 4 배의 캐시 대역폭이 필요합니다. 데이터 크기는 얼마나됩니까? L1 캐시에 맞습니까?
Mysticial

답변:


3

Vtune에서 EMON 프로파일 링 또는 oprof와 같은 동등한 도구를 사용해보십시오.

EMON (Event Monitoring) 프로파일 링 => 시간 기반 도구와 비슷하지만 어떤 성능 이벤트가 문제를 일으키는 지 알려줄 수 있습니다. 하지만 튀어 나오는 특정 지침이 있는지 확인하려면 먼저 시간 기반 프로필로 시작해야합니다. (그리고 해당 IP에서 은퇴 지연이 얼마나 자주 발생했는지 알려주는 관련 이벤트가있을 수 있습니다.)

EMON 프로파일 링을 사용하려면 "일반적인 의심"에서 ...에 이르기까지 다양한 이벤트 목록을 실행해야합니다.

여기서는 캐시 미스, 정렬부터 시작합니다. 사용중인 프로세서에 RF 포트 제한에 대한 카운터가 있는지는 모르겠지만-그래야합니다.하지만 오래 전에 EMON 프로파일 링을 추가했으며 마이크로 아키텍처에 적합한 이벤트를 추가하여 얼마나 잘 따라 가는지 모르겠습니다.

프론트 엔드, 명령 페치, 스톨 일 수도 있습니다. 어쨌든이 지침에는 몇 바이트가 있습니까? 이를위한 EMON 이벤트도 있습니다.


Nehalem VTune이 L3 이벤트를 볼 수 없다는 의견에 대한 응답 : 사실이 아닙니다. 댓글에 추가했지만 적합하지 않은 내용은 다음과 같습니다.

실제로 LL3 / L3 $ / 소위 Uncore에 대한 성능 카운터가 있습니다. VTune이 그들을 지원하지 않는다면 나는 엄청나게 놀랄 것입니다. http://software.intel.com/sites/products/collateral/hpc/vtune/performance_analysis_guide.pdf를 참조 하십시오.VTune 및 PTU와 같은 기타 도구를 가리 킵니다. 실제로 LL3 이벤트가없는 경우에도 David Levinthal은 "인텔 ® 코어 ™ i7 프로세서에는 아이테니엄 ® 프로세서 제품군 데이터 EAR 이벤트와 매우 유사한"대기 이벤트 "가 있습니다.이 이벤트는로드를 샘플링하여 수를 기록합니다. 명령 실행과 실제 데이터 전달 사이를 순환합니다. 측정 된 대기 시간이 MSR 0x3f6, 비트 15 : 0에 프로그래밍 된 최소 대기 시간보다 크면 카운터가 증가합니다. 카운터 오버플로는 PEBS 메커니즘을 준비하고 다음 단계에서 대기 시간 임계 값을 충족하는 이벤트, 측정 된 대기 시간, 가상 또는 선형 주소 및 데이터 소스는 PEBS 버퍼의 3 개의 추가 레지스터에 복사됩니다. 가상 주소는 알려진 위치로 캡처되기 때문에 샘플링 드라이버는 가상에서 물리적으로의 변환을 실행하고 물리적 주소를 캡처 할 수도 있습니다. 물리적 주소는 NUMA 홈 위치를 식별하며 원칙적으로 캐시 점유에 대한 세부 정보를 분석 할 수 있습니다. "그는 또한 35 페이지의 L3 CACHE_HIT_UNCORE_HIT 및 L3 CACHE_MISS_REMOTE_DRAM과 같은 VTune 이벤트를 가리 킵니다. 때로는 숫자를 조회해야합니다. 코드를 작성하고 VTune의 하위 인터페이스에 프로그래밍하지만이 경우 예쁜 사용자 인터페이스에서 볼 수 있다고 생각합니다.


좋아, http://software.intel.com/en-us/forums/showthread.php?t=77700&o=d&s=lr 에서 러시아의 VTune 프로그래머가 Uncore에서 샘플링 할 수 없다고 "설명"합니다. 이벤트.

예를 들어 하나의 CPU 만 활성화하고 의미있게 샘플링 할 수 있습니다. 또한 L3가 CPU로 돌아갈 때 누락 된 데이터를 표시하는 기능이 있다고 생각합니다. 실제로 전체적으로 L3는 데이터를 반환하는 CPU를 알고 있으므로 확실히 샘플링 할 수 있습니다. 어떤 하이퍼 스레드를 모를 수도 있지만 다시 비활성화하여 단일 스레드 모드로 전환 할 수 있습니다.

그러나 일반적으로이 작업을 수행하려면 VTune이 아닌 주변에서 작업해야하는 것처럼 보입니다.

먼저 지연 시간 프로파일 링을 시도하십시오. 그것은 전적으로 CPU 내부에 있으며 VTune 사람들은 그것을 너무 많이 엉망으로 만들지 않을 것입니다.

그리고 다시 말씀 드리지만, 문제가 L3가 아닌 핵심에있을 가능성이 있습니다. 따라서 VTune이이를 처리 할 수 ​​있어야합니다.


Levinthal에 따라 "Cycle Accounting"을 사용해보십시오.


당신의 반응에 감사드립니다. VTune을 사용하여 응용 프로그램을 분석하지만 nehalem 아키텍처의 문제는 L3 캐시 off-core가 코어 부분에 속하므로이 부분에 사용할 수있는 성능 이벤트 카운터가 없다는 것입니다. 따라서 캐시 미스 등을 추정하는 것은 어렵습니다.
Ricky

실제로 LL3 / L3 $ / 소위 Uncore에 대한 성능 카운터가 있습니다. VTune이 그들을 지원하지 않는다면 나는 엄청나게 놀랄 것입니다. software.intel.com/sites/products/collateral/hpc/vtune/…
Krazy Glew

댓글에 들어갈 수있는 것보다 더 많이 썼고 답으로 옮기고 원래 댓글을 정리하려고했지만 댓글은 5 분 동안 만 편집 할 수 있습니다. 짧은 버전 : VTune을 사용하면 L3 캐시 누락을 볼 수 있습니다. Uncore 지원 없이도 지연 프로파일 링을 사용하며 Uncore를 지원합니다.
Krazy Glew 2012

그리고 전반적으로 귀하의 문제는 L3 캐시 누락이 아니라고 생각합니다. 프런트 엔드 이벤트 일 가능성이 높습니다.
Krazy Glew 2012

@KrazyGlew : 당신의 추측이 맞습니다. 그는 러시아 연방에서 온 러시아 사람입니다. 여기 링크드 인에 자신의 프로필입니다 - linkedin.com/in/vtsymbal
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.