선택한 단어 수는 입니다.
최소 단어 이상 선택하여야 합니다.
최소 단어 이상 선택하여야 합니다.
선택한 단어 수는 30입니다.
최대 10 단어까지만 선택 가능합니다.
최대 10 단어까지만 선택 가능합니다.
문제 정의
- 본 연구는 효율적인 메모리 접근 시스템으로 융합알고리즘과 GPU 코어 할당 알고리즘을 제안하였다. CPU-GPU간의 공유메모리 알고리즘에서 메모리 중심에 처리방식은 기존의 CUDA나 OpenCL보다 우월한 것으로 나타났다.
가설 설정
- 프리페처는 L2에 다음 처리할 데이터를 가져오고 이미 처리된 데이터는 메인 메모리에서 해당 데이터를 Flush한다. D) GPU는 위임받은 데이터 작업이 끝나면 완료(Clear) 신호를 작업관리자에게 보내며 작업관리자는 CPU에 GPU의 작업완료를 전달한다.
제안 방법
- 본 연구는 CPU와 GPU 간의 직접적인 데이터 복사 없이 CPU가 요청한 데이터의 주소 정보를 제공받아 메모리 테이블 관리자 계층에서 GPU 캐시에 맞게 상호 변환·분배·제어하고, 데이터 로드에 따라 GPU 셀을 할당하는 퓨전 알고리즘을 제안하였다.
- 2장에서는 기존의 이기종 시스템구조와 제안된 알고리즘을 설명하였다. 3장은 본 제안 알고리즘에 GPU Cell 효율적인 처리를 로디니아 벤치를 통해 검증하고, 개발된 융합 구조 분석기(Fusion Architecture Analyzer, FAA)를 이용해 제안된 기법과 기존의 OpenCL, OpenMP, CUDA과의 비교성능분석을 하였다.
- 최적화된 코어 수가 현재 동작하는 코어 수(Nruning) 보다 크면, 작업이 할당되지 않은 GPU의 코어를 할당한다. 최적화된 코어 수가 현재 동작하는 코어 수보다 작으면, 최적화된 코어 수와 동작하는 코어 수를 비교한다. 현재 동작하는 코어 개수가 최적화된 코어 수보다 많다면, 현재 동작하고 있는 코어 중 작업이 할당되지 않는 코어에 코의 할당작업을 추가하며, 전체 코어가 동작한다면,할당 작업이 가장적은 코어에 할당한다.
- 앞서 제안된 알고리즘에 맞춰 GPU 자원에 효율성을 분석하였다. GPU 자원 낭비에 대한 성능 분석을 위해 로디니아 벤치(Rodinia Benchmark)와 오픈소스를 이용하였다 [12].
- GPU 자원 낭비에 대한 성능 분석을 위해 로디니아 벤치(Rodinia Benchmark)와 오픈소스를 이용하였다 [12]. 앞 장에서 논의한 Computing / Memory-intensive 중, GPU 코어에 따라 성능이 향상되지 못한 Memory-intensive의 응용 어플리케이션인 NW, Srad, Kmean, Bfs를 비교분석하였다. 그림 9와 그림 6의 비교에서 본 제안 알고리즘이 NW에서는 큰 향상이 없었지만,Srad와 Kmean, Bfs에서는 GPU 코어가 증가 될수록 높은 성능을 보여줄 수 있었다.
- 선행연구에서 자체 개발한 FAA(Fusion Architecture Analyzer)를 QEMU와 연동하여 개발하였다 [13]. 하지만 FAA를 QEMU의 연동에서 성능과 상관없는 메인메모리의 오버헤드가 발견되었다.
- 하지만 FAA를 QEMU의 연동에서 성능과 상관없는 메인메모리의 오버헤드가 발견되었다. 따라서 이를 개선하기 위해 그림 12과 같이 OpenMPv4.0, OpenCL v1.2, CUDA v6.5, Fusion v1.1을 라이브러리, 컴파일러로 분리하고, 별도의 융합구조 에뮬레이터를 QEMU에 동작하던 해당 라이브러리와 컴파일러를 하드웨어기반으로 독립시켰다. UI는 Windows 기반으로 제작하였으며, UI는 요소 테스트를 하는 Control Block과 개별 그래픽을 컨트롤하는 Analysis Block으로 구분되며, 이를 측정하는 개별 코어와 알고리즘별 분석시간과 분야별 요소가 확인할 수 있다.
대상 데이터
- 표 1은 벤치마크한 환경을 나타내었다. CUDA 성능과 비교분석하기 위해서 NVIDIA사 X1 모바일칩의 GPU와 재원이 비슷한 K620을 선택하였다.
데이터처리
- 3장의 성능비교분석은 4장의 표1과 같은 환경에서 기존 GPU를 이용한 기법과과 제안된 GPU-CPU 공유알고리즘을 비교분석을 수행하였다.
이론/모형
- 앞서 제안된 알고리즘에 맞춰 GPU 자원에 효율성을 분석하였다. GPU 자원 낭비에 대한 성능 분석을 위해 로디니아 벤치(Rodinia Benchmark)와 오픈소스를 이용하였다 [12]. 앞 장에서 논의한 Computing / Memory-intensive 중, GPU 코어에 따라 성능이 향상되지 못한 Memory-intensive의 응용 어플리케이션인 NW, Srad, Kmean, Bfs를 비교분석하였다.
성능/효과
- 결과적으로 GPU와 CPU의 최대버스폭은 336.3 GB/s, 17.0∼68.2GB/s으로 GPU대비 1/5∼1/20의 버스폭을 갖는다.
- 본 연구는 CPU와 GPU 간의 직접적인 데이터 복사 없이 CPU가 요청한 데이터의 주소 정보를 제공받아 메모리 테이블 관리자 계층에서 GPU 캐시에 맞게 상호 변환·분배·제어하고, 데이터 로드에 따라 GPU 셀을 할당하는 퓨전 알고리즘을 제안하였다. 기능에 따라 작업관리자(Job Manager)와 리매퍼(Re-mapper)와 프리페처(Re-fetcher)로 분류하여 CPU-GPU 간 데이터 처리에 병목현상(Bottleneck)을 줄이고, GPU의 셀을 효율적으로 배분함으로써 모바일 시스템에서 이기종 시스템구조보다 에너지 절감을 할 수 있다. 부가적으로 전체일관성을 위한 스누핑이 작업관리자에 맞춰 소단위로 유지됨으로 두 유닛간의 오버헤드도 감소하고, GPU의 성능저하가 감소된다.
- 본 제안은 그림 2와 같이 L3 캐쉬 코드 정보와메인메모리 데이터를 개발된 ‘작업 관리자(Job Manager)’와 ‘캐시 컨트롤러(Cache Controller)’‘리맵퍼(Re-mapper)’ 그리고 ‘프리페처(Pre–fetecher)’로 CPU-GPU간 주소를 공유하고 GPU 코어에서 물리 메인 메모리에 직접적인 접근을 위한 데이터 주소 변환 역할을 통해 GPU의 접근빈도 및 크기에 큰 영향 없이 처리가 가능하고 가상메모리 구조로 인한 오버헤드도 줄일 수 있다.
- 그림 6과 같이 왼쪽 4개의Compute-intensive 계열 알고리즘 중 LavaMD와 Backprop는 코어 수에 따라 비래한 성능을 보이며, Pathfinder, Backprop은 조금 낮지만 증가됨을 확인할 수 있다. 하지만 메모리의 의존도가 높은 Memory-intensive 알고리즘들 중 Bfs는 코어 변화 따라 미약하게 성능이 증가한 반면에 Kmean는 코어 8개보다 16개가 오히려 성능이 감소됨을 알 수 있었다
- 그림 7의 코어 개수가 변화함에 따른 IPC 코어 1개를 기준으로 정규화한 그래프로 Computeintensive는 코어 수 증가에 따라 개별 코어 성능이 크게 떨어지지 않지만, Memory-intensive는 코어 수 증가에 따라 개별 코어 성능이 크게 떨어지는 것을 알 수 있다. 평균으로 볼 때 코어 1개일 때보다 16개에서는 Memory-intensive에서는 16% 수준으로 IPC가 크게 감소하는 반면에, Computeintensive는 81.3%으로 감소폭이 작았다. CPUGPU메모리 공유구조에서 어떤 형태의 응용프로그램 인지를 판별하여 그 특성에 따라 GPU 코어 할당을 하는 것이 중요하다.
- 앞 장에서 논의한 Computing / Memory-intensive 중, GPU 코어에 따라 성능이 향상되지 못한 Memory-intensive의 응용 어플리케이션인 NW, Srad, Kmean, Bfs를 비교분석하였다. 그림 9와 그림 6의 비교에서 본 제안 알고리즘이 NW에서는 큰 향상이 없었지만,Srad와 Kmean, Bfs에서는 GPU 코어가 증가 될수록 높은 성능을 보여줄 수 있었다.
- 또한 NW와 같은 알고리즘에서는 향상이 없었다. 반면, Strad,Kmean, Bfs 알고리즘의 8, 16개의 코어 비교에서는 성능이 크게 향상되었으며, 특히 Kmean에서가장 크게 향상되는 것으로 나타났다. 그림 11에서도 그림 10의 IPC 결과와 비슷한 결과를 그래프로 나타낼 수 있었다.
- 그림 11에서도 그림 10의 IPC 결과와 비슷한 결과를 그래프로 나타낼 수 있었다. Latency는 NW는 그림 8과 비교했을 때 큰 변화가 없는 반면에 Stad, Kmean,Bfs에서 코어가 증가할수록 성능 향상 효과가 컸으며, 4코어 이하에서는 성능향상 효과가 미진했다.
- 제안된 알고리즘은 GPU-CPU 연동에서 메인메모리에서 직접 읽고 쓰기 때문에 오버헤드가 작지만 Open, CUDA는 경우 가상메모리 영역으로 인해 GPU-CPU의 공유메모리에 복사가 빈번함에 따라 오버헤드에 180∼300%를 차지하였다.
- Mandatory는 순수한 연산을 나타내며, Overhead는 메인메모리 공유 아키텍처에서 발생하는 메인메모리 오버헤드를 나타낸다. 앞장의 GPU코어에 따른 알고리즘에 비교에서 메모리접근지연으로 발생되는 오버헤드가 전체 시스템 계산 시간에 영향을 주면서, 전체 수행시간이 지연되었다. 제안된 방식이 순수 연산에서는 다른 아키텍처와 비슷한 성능을 보인다.
- 그림 15, 16은 이미지 압축과 스테레오 이미지변환으로 성능 평가를 하였다. 이미지 압축 성능에서는 OpenCL보다 빠른 처리속도와 메인메모리의 오버헤드도 적었다. 하지만 CUDA에 비해서 상대적인 메모리 오버헤드가 컸으며, 전체처리시간도 CUDA 아키텍처보다 3~4%정도 느린 것으로 나타났다.
- 이미지 압축 성능에서는 OpenCL보다 빠른 처리속도와 메인메모리의 오버헤드도 적었다. 하지만 CUDA에 비해서 상대적인 메모리 오버헤드가 컸으며, 전체처리시간도 CUDA 아키텍처보다 3~4%정도 느린 것으로 나타났다. 본 제안의 기법은 앞장의 Computeintensive의 알고리즘 비교와 그림 15의 결과로 볼 때 제안된 기법의 개선 필요가 있다는 것을 알 수 있다.
- 하지만 CUDA에 비해서 상대적인 메모리 오버헤드가 컸으며, 전체처리시간도 CUDA 아키텍처보다 3~4%정도 느린 것으로 나타났다. 본 제안의 기법은 앞장의 Computeintensive의 알고리즘 비교와 그림 15의 결과로 볼 때 제안된 기법의 개선 필요가 있다는 것을 알 수 있다. 그림 16의 스테레오 이미지 필터의 벤치마크 결과에서 제안된 알고리즘이 150~330%가량 메모리 효율성이 높았다.
- 본 제안의 기법은 앞장의 Computeintensive의 알고리즘 비교와 그림 15의 결과로 볼 때 제안된 기법의 개선 필요가 있다는 것을 알 수 있다. 그림 16의 스테레오 이미지 필터의 벤치마크 결과에서 제안된 알고리즘이 150~330%가량 메모리 효율성이 높았다.
- 본 연구는 효율적인 메모리 접근 시스템으로 융합알고리즘과 GPU 코어 할당 알고리즘을 제안하였다. CPU-GPU간의 공유메모리 알고리즘에서 메모리 중심에 처리방식은 기존의 CUDA나 OpenCL보다 우월한 것으로 나타났다. 또한, GPU 주위의 연산방식의 메인메모리 공유 및 할당에서 효율성을 보였다.
- CPU-GPU간의 공유메모리 알고리즘에서 메모리 중심에 처리방식은 기존의 CUDA나 OpenCL보다 우월한 것으로 나타났다. 또한, GPU 주위의 연산방식의 메인메모리 공유 및 할당에서 효율성을 보였다. 벡터의 덧셈과 곱셈 그리고 스테레오 이미지 성능 비교에서는 최소 55%부터 최대 330%, 평균 220%의 높은 성을 보여줄 수 있었다.
- 또한, GPU 주위의 연산방식의 메인메모리 공유 및 할당에서 효율성을 보였다. 벡터의 덧셈과 곱셈 그리고 스테레오 이미지 성능 비교에서는 최소 55%부터 최대 330%, 평균 220%의 높은 성을 보여줄 수 있었다. 하지만 이미지 압축 성능과 같이 CPU 중심에 GPU 공유메모리 아키텍처에서는 CUDA에 비해 메모리 효율성이 낮은 것으로 나타났으며, 앞으로는 결과분석에서 나타난 문제를 개선하는 연구를 진행할 예정이다.
후속연구
- 4가지 분석에서 Compute-intensive 관련된 성능 개선이 필요하며, 향후 연구에도 CPU 코어 중심에 처리에서 GPU의 효율성과 CPU의 메인 메모리 접근의 효율성을 높이는 추가적인 알고리즘이 요구된다.
- 벡터의 덧셈과 곱셈 그리고 스테레오 이미지 성능 비교에서는 최소 55%부터 최대 330%, 평균 220%의 높은 성을 보여줄 수 있었다. 하지만 이미지 압축 성능과 같이 CPU 중심에 GPU 공유메모리 아키텍처에서는 CUDA에 비해 메모리 효율성이 낮은 것으로 나타났으며, 앞으로는 결과분석에서 나타난 문제를 개선하는 연구를 진행할 예정이다.
※ AI-Helper는 부적절한 답변을 할 수 있습니다.