GPU에서 비교가 왜 그렇게 비쌉니까?


10

충돌 감지 클래스의 성능을 향상시키는 동안 gpu에서 보낸 시간의 ~ 80 %가 루프를 통과 해야하는 버킷의 경계를 파악하려는 경우 if / else 조건에 소비되는 것으로 나타났습니다.

더 정확하게:

  1. 각 스레드는 ID를 얻습니다.이 ID로 메모리에서 삼각형을 가져옵니다 (각 정수 3 개). 그러면 3만큼 정점을 가져옵니다 (3은 각각 float).

  2. 그런 다음 정점을 정수 격자 점 (현재 8x8x8)으로 변환하고 해당 격자의 삼각형 경계로 변환합니다.

  3. 3 개의 점을 경계로 변환하기 위해 각 점 중 각 차원의 최소 / 최대를 찾습니다.

내가 사용하는 프로그래밍 언어에 minmax 내장 함수가 누락되었으므로 직접 만들었습니다.

procedure MinMax(a, b, c):
   local min, max

   if a > b:
      max = a
      min = b
   else:
      max = b
      min = a
   if c > max:
      max = c
   else:
      if c < min:
         min = c

   return (min, max)

따라서 평균적으로 2.5 * 3 * 3 = 22.5 비교 여야합니다. 실제 삼각형-모서리 교차 테스트보다 약 많은 시간을 소비합니다 (약 100 * 11-50 지침).

사실, CPU에서 필요한 버킷을 사전 계산하고 (단일 스레드, 벡터화 없음) 버킷 정의와 함께 GPU보기에서 스택하고 GPU가 스레드 당 ~ 4 추가 읽기를 수행하는 것이 시도보다 6 배 빠릅니다. 그 자리에서 경계를 알아낼 수 있습니다. (동적 메쉬를 다루기 때문에 매 실행 전에 재 계산됩니다.)

그렇다면 왜 GPU에서 비교가 그렇게 끔찍한가요?


2
귀하의 질문은 특정 유형의 하드웨어에서 특정 코드 조각의 명령 수준 성능에 관한 것입니다. 그것은 컴퓨터 과학 질문보다 프로그래밍 질문과 훨씬 흡사합니다.
David Richerby 2012

7
생각 에 그것은 비싸지 만 가지 가 아닌 비교 입니다. 컴파일러가 예측을 사용하지 않으면 (또는 GPU가이를 제공하지 않는 경우) "스레드"분기 (GPU가 SIMD 지향이기 때문에)를 발생시키는 분기가 사용됩니다. 조건을 마스크로 변환하고 마스크를 사용하여 조건부 이동 / 스왑을 합성하는 것이 합리적인 대안 일 수 있습니다.
Paul A. Clayton

1
@DavidRicherby 나는 그것이 특정인지 확실하지 않습니다. 이 질문이 SIMD 아키텍처에 적용되지 않습니까?
kasperd

1
@DavidRicherby : CS 부서에서 comp arch를 가르치는 이유는 comp arch가 선택한 알고리즘에 영향을 미치기 때문입니다. SIMD 아키텍처는 중첩 분기없이 프로그램을 작성하는 방법을 알아낼 수있는 경우에만 높은 처리량을 생성 할 수 있습니다.
방황 논리

2
Wandering Logic 상태의 대답이 덜 분명한 방식으로 GPU는 많은 "스레드"가 동시에 동일한 명령에 있다고 가정하여 작동합니다. 따라서 GPU는 대략적인 지점이 아닌 모든 지점을 취합니다. 이것이 바로 GPU가 이웃이 일반적으로 동일한 브랜치를 취하는 사실을 악용하는 이유입니다. 이것이 사실이 아닌 경우 성능이 끔찍합니다.
Rob

답변:


10

GPU는 SIMD 아키텍처입니다. SIMD 아키텍처에서는 처리하는 모든 요소에 대해 모든 명령을 실행해야합니다. (이 규칙에는 예외가 있지만 거의 도움이되지 않습니다).

따라서 MinMax일상적으로 모든 호출에서 세 가지 분기 명령어를 모두 가져와야 할뿐만 아니라 (평균 2.5 개만 평가되는 경우에도) 모든 할당 명령문도주기를 사용합니다 (실제로 "실행"되지 않은 경우에도) ).

이 문제를 때때로 스레드 발산 이라고 합니다 . 컴퓨터에 32 개의 SIMD 실행 레인이있는 경우 여전히 단일 페치 장치 만 갖습니다. 여기에서 "스레드"라는 용어는 기본적으로 "SIMD 실행 레인"을 의미합니다. 따라서 내부적으로 각 SIMD 실행 레인에는 "I 'm enabled / disabled"비트가 있으며 지점은 실제로 해당 비트를 조작합니다. 단, 모든 SIMD 레인이 비활성화되는 시점에서는 페치 장치가 일반적으로 "else"절로 바로 이동합니다.

따라서 코드에서 모든 SIMD 실행 레인은 다음을 수행합니다.

compare (a > b)
assign (max = a if a>b)
assign (min = b if a>b)
assign (max = b if not(a>b))
assign (min = a if not(a>b))
compare (c > max)
assign (max = c if c>max)
compare (c < min if not(c>max))
assign (min = c if not(c>max) and c<min)

일부 GPU의 경우 GPU가 자체적으로 수행하는 경우 조건부에서 예측으로의 변환이 느려질 수 있습니다. @ PaulA.Clayton이 지적한 것처럼 프로그래밍 언어 및 아키텍처에 조건부 조건부 이동 작업 (특히 형식 중 하나 if (c) x = y else x = z)이있는 경우 더 잘 수행 할 수 있습니다. (그러나 아마별로 좋지는 않습니다).

또한, 상기 배치 c < min조건 내측 else의 것은 c > max불필요하다. 그것은 확실히 당신을 아무것도 저장하지 않으며 (GPU가 자동으로 예측으로 변환해야한다는 사실을 감안할 때) 실제로 두 개의 다른 조건에 중첩되어 아프게 될 수 있습니다.


2
(이 부분이 확실하지 않다면 죄송합니다. 이론가들이 주제를 벗어난 주제로 질문을 닫기 전에 답을 구하려고합니다.)
Wandering Logic

기본 사항에 대한 자세한 내용은 다음을 참조하십시오. http.developer.nvidia.com/GPUGems2/gpugems2_chapter34.html 최신 해결 방법 : eecis.udel.edu/~cavazos/cisc879/papers/a3-han.pdf
Fizz

일부 알고리즘은 SIMD 병렬 처리를 통해 속도를 높일 수 없다는 점에서 주제에 관한 것입니다. (예 : 더 이론적 인 이유에 대한 작업, 스팬 등)
Rob

1
여기에 발산의 TEH 기본에 다른 강의의 people.maths.ox.ac.uk/gilesm/cuda/lecs/lec3-2x2.pdf의 (엔비디아에 어쨌든) 문제는 당 워프 것을이에서 주. 다른 날실에서 실행되는 코드는 행복하게 발산 될 수 있습니다. 그리고 그것을 피하는 방법을 제안하는 또 다른 논문 : hal.inria.fr/file/index/docid/649650/filename/sbiswi.pdf
Fizz

약간 다른 점이 있지만 eprint.iacr.org/2012/137.pdf 질문에 쓴 의견에 따라 읽을 가치가 있습니다. 예상치 못한 성능에 비해 10 배의 속도 저하는 GPU에 대해 "정상적"일 수 있습니다 어셈블리에 (일반적으로 공식적으로 지원되지 않는 도구와 함께). GPU 타겟팅 컴파일러가 나아질 수는 있지만 숨을 쉬지 않을 것입니다.
Fizz
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.