병렬처리는 결국 필수 불가결한 요소가 될 것임에는 분명하다. 확실히 단일 코어 발전 대비 성능 비율이 언젠가부터 매우 낮아진다는 것을 확인할 수 있다. CPU 를 듀얼 혹은 쿼드로 쓰는 것도 꽤 매리트가 있지만, 알고리즘을 연구하는 사람으로써 그런 한 두개의 병렬을 가지고 큰 효과를 보기에는 그 한계가 명확하다.
결국 요래저래 살펴보다가 또다시 GPU 쪽으로 눈이 돌아가게 되었는데, 그 당시에는 그렇게 어렵게만 느껴지던 CUDA 라는 것이 그렇게 어려운 녀석이 아니었다.
일련의 흐름에 따라서 프로그래밍을 하면 되는데,
1. 디바이스의 초기화
2. GPU 상의 메모리 할당 ( cudaMalloc )
3. CPU 상에서 GPU 상으로 처리할 내용을 복사 ( cudaMemcpy )
4. 커널을 수행함으로써 원하는 연산 처리 ( function <<< blocks, threads, sharedmem >>> ( parameters ) )
5. GPU 상에서 처리된 내용을 CPU 상으로 재 이동 ( cudaMemcpy )
6. 할당했었던 메모리를 모두 해제 ( cudaFree )
7. 디바이스 종료
이러한 큰 흐름을 순서로 움직이면 된다.
얼마나 쉬운가?
마치 포인터를 처음 볼때의 그런 느낌이었다. 어라? 별거 아니네?
그런데 이놈도 포인터랑 똑같은 놈이더라. 결국 잘 쓰려고 하다보니 메모리 구조에 대한 것을 다시 확인해야 했다. CUDA 의 처리는 Block 단위의 다수의 스레드를 어떻게 관리하느냐, 그리고 이들이 처리될 때의 Shared Memory 를 잘 관리해 줘야 올바른 결과를 얻을 수 있고, 획기적인 병렬처리의 성능을 만끽할 수 있다는 것. 게다가 망할 포인터보다도 하나 더 많은 요소가 있었으니, Block 과 Thread 의 숫자를 결정해주는 것이다.
하지만 확실한 건 포인터와 마찬가지로 이놈도 쉽게 생각하면 될 것 같은 기분이 든다.
다음 번엔 SGA 에 Evaluation 과정을 CUDA 를 이용해 처리한 소스나 올려봐야 겠다. 아직 Thread 동기화에 문제가 있는지, 자꾸 마지막 변수값만 들어가는 현상이 발생하던데 요고만 해결하고 나서 하나씩 또 정리해봐야겠다.
결국 요래저래 살펴보다가 또다시 GPU 쪽으로 눈이 돌아가게 되었는데, 그 당시에는 그렇게 어렵게만 느껴지던 CUDA 라는 것이 그렇게 어려운 녀석이 아니었다.
일련의 흐름에 따라서 프로그래밍을 하면 되는데,
1. 디바이스의 초기화
2. GPU 상의 메모리 할당 ( cudaMalloc )
3. CPU 상에서 GPU 상으로 처리할 내용을 복사 ( cudaMemcpy )
4. 커널을 수행함으로써 원하는 연산 처리 ( function <<< blocks, threads, sharedmem >>> ( parameters ) )
5. GPU 상에서 처리된 내용을 CPU 상으로 재 이동 ( cudaMemcpy )
6. 할당했었던 메모리를 모두 해제 ( cudaFree )
7. 디바이스 종료
이러한 큰 흐름을 순서로 움직이면 된다.
얼마나 쉬운가?
마치 포인터를 처음 볼때의 그런 느낌이었다. 어라? 별거 아니네?
그런데 이놈도 포인터랑 똑같은 놈이더라. 결국 잘 쓰려고 하다보니 메모리 구조에 대한 것을 다시 확인해야 했다. CUDA 의 처리는 Block 단위의 다수의 스레드를 어떻게 관리하느냐, 그리고 이들이 처리될 때의 Shared Memory 를 잘 관리해 줘야 올바른 결과를 얻을 수 있고, 획기적인 병렬처리의 성능을 만끽할 수 있다는 것. 게다가 망할 포인터보다도 하나 더 많은 요소가 있었으니, Block 과 Thread 의 숫자를 결정해주는 것이다.
하지만 확실한 건 포인터와 마찬가지로 이놈도 쉽게 생각하면 될 것 같은 기분이 든다.
다음 번엔 SGA 에 Evaluation 과정을 CUDA 를 이용해 처리한 소스나 올려봐야 겠다. 아직 Thread 동기화에 문제가 있는지, 자꾸 마지막 변수값만 들어가는 현상이 발생하던데 요고만 해결하고 나서 하나씩 또 정리해봐야겠다.
