GPU는 컴퓨팅에서 어떤 미래를 가지고 있습니까?[닫은]
https://stackoverflow.com/questions/1126989
-
13-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian문제
귀하의 CPU는 쿼드 코어일 수 있지만 오늘날 일부 그래픽 카드에는 200개 이상의 코어가 있다는 사실을 알고 계셨습니까?우리는 오늘날 그래픽 카드의 GPU가 그래픽과 관련하여 무엇을 할 수 있는지 이미 살펴보았습니다.이제는 그래픽이 아닌 작업에도 사용할 수 있으며, 제 생각에는 그 결과가 정말 놀랍습니다.병렬성에 적합한 알고리즘은 CPU에서보다 GPU에서 훨씬 더 빠를 가능성이 있습니다.
이 모든 것을 가능하게 하는 몇 가지 기술이 있습니다.
1.) 쿠다 엔비디아.가장 잘 알려져 있고 문서화도 잘 되어 있는 것 같습니다.불행히도 NVidia 비디오 카드에서만 작동합니다.SDK를 다운로드하고 일부 샘플을 시험해보았는데 CUDA에서 수행되고 있는 몇 가지 멋진 작업이 있습니다.그러나 그것이 NVidia 카드에만 국한되어 있다는 사실은 나로 하여금 그것의 미래에 의문을 갖게 만듭니다.
2.) 개울 ATI에 의해.ATI는 CUDA와 동일합니다.예상할 수 있듯이 ATI 카드에서만 작동합니다.
3.) 오픈CL - 크로노스 그룹은 이 표준을 마련했지만 아직 초기 단계입니다.하지만 저는 OpenCL의 아이디어를 좋아합니다.대부분의 비디오 카드 제조업체에서 이를 지원하고 크로스 비디오 카드 개발을 훨씬 쉽게 만들 수 있기를 바랍니다.
하지만 비그래픽 GPU 프로그래밍을 위한 다른 기술은 무엇이 있으며 가장 유망한 것은 무엇입니까?그리고 이러한 기술이 .NET과 같은 일부 주류 개발 프레임워크에 내장되어 훨씬 더 쉬워지는 것을 보고 싶습니까?
해결책
나는이 기술이 인기 있고 주류가 될 것이라고 예측하지만 그렇게하는 데 시간이 걸릴 것입니다. 제 생각에는 약 5 ~ 10 년이 걸립니다.
올바르게 언급했듯이 기술 채택에 대한 주요 장애물 중 하나는 ATI와 NVIDIA와 같은 대부분의 어댑터에서 실행되는 공통 라이브러리가 부족하다는 것입니다. 이것이 허용되는 정도로 해결 될 때까지, 기술은 주류에 들어 가지 않으며 특정 하드웨어에서 실행되는 맞춤형 애플리케이션의 틈새 시장에 머물게됩니다.
C# 및 기타 높은 수준의 관리 언어와 통합하는 경우 (이는 조금 더 오래 걸리지 만 XNA는 이미 사용자 지정 셰이더와 관리 환경이 어느 정도 혼합 될 수 있음을 보여줍니다. 물론 셰이더 코드는 여전히 C#에 있지 않으며 그렇게하는 데 몇 가지 주요 장애물이 있습니다.
GPU 코드를 빠르게 실행하는 주된 이유 중 하나는 코드가 할 수있는 것과 할 수없는 일에 심각한 제한이 있고 일반적인 RAM 대신 VRAM을 사용하기 때문입니다. 이로 인해 CPU 코드와 GPU 코드를 하나로 모으기가 어렵습니다. 해결 방법은 가능하지만 실제로 성능 이득을 부정합니다.
내가 볼 수있는 가능한 솔루션 중 하나는 제한이있는 C#에 대한 하위 언어를 만드는 것입니다. GPU 코드로 컴파일되며 USUSAL C# 코드와 통신하는 방법이 엄격하게 정의됩니다. 그러나 이것은 우리가 이미 가지고있는 것과 크게 다르지 않을 것입니다. 일부 구문 설탕과 표준 라이브러리 기능 때문에 글을 쓰는 것이 더 편안합니다. 그럼에도 불구하고, 이것도 지금도 나이가 들었습니다.
다른 팁
다음 Directx를 GPU를 사용하는 또 다른 방법으로 계산할 수 있다고 생각합니다.
내 경험을 통해 GPU는 병렬화하기 쉬운 알고리즘의 경우 매우 빠릅니다. 나는 최근 Cuda의 특수 이미지 크기 조정 알고리즘을 쿼드 코어 인텔 프로세서보다 GPU에서 100 배 더 빠른 것으로 최적화했습니다. 문제는 데이터를 GPU로 가져온 다음 결과를 메인 메모리로 다시 가져 오는 것이 2GB/s 미만인 해당 기계의 memcpy () 속도로 제한된 두 방향으로 가져 왔습니다. 결과적으로 알고리즘은 CPU 버전보다 약간 빠릅니다 ...
그래서 그것은 실제로 달라집니다. GPU의 대부분의 데이터를 유지할 수있는 과학적 응용 프로그램이있는 경우 모든 알고리즘이 GPU 구현에 맵핑 된 경우 정상입니다. 그렇지 않으면 나는 CPU와 GPU 사이에 더 빠른 파이프가있을 때까지 기다리거나 ATI가 결합 된 칩으로 소매를 가지고 있는지 보자.
사용해야 할 기술에 대해 : Cuda에서 물건을 실행하면 OpenCL (또는 다른 언어)에 포트를 제공하는 추가 단계는 그리 크지 않습니다. 알고리즘을 병렬화하여 모든 무거운 작업을 수행했으며 나머지는 다른 '맛'입니다.
Monte Carlo는 당황스럽게 평행하지만 재무 및 과학 컴퓨팅의 핵심 기술입니다.
응답자 중 한 명이 대부분의 실제 문제가 이러한 유형의 작업으로 쉽게 분해 될 수 없다고 말하기는 약간 부정확합니다.
많은 과학적 조사는 당황스럽게 평행 한 방식으로 표현할 수있는 것을 활용하여 수행됩니다.
"부끄럽게"평행이라고해서 그것이 매우 중요한 필드가 아니라는 것을 의미하지는 않습니다.
나는 여러 금융 주택에서 일했고, 우리는 여러 대형 NVIDIA CUDA 설치를 위해 1000 개 이상의 Montecarlo 엔진 (많은 블레이드 스택이 함께 줄 지어 있음)의 농장을 버릴 수 있다고 예상합니다. 데이터 센터의 전력 및 열 비용을 크게 줄입니다.
한 가지 중요한 아키텍처 이점 중 하나는 데이터를 공급하고 결과를보고 해야하는 기계가 훨씬 적기 때문에 네트워크로드가 훨씬 적다는 것입니다.
그러나 기본적으로 이러한 기술은 C#과 같은 관리 런타임 언어보다 추상화 수준이 낮으며, 자체 프로세서에서 자체 코드를 실행하는 하드웨어 장치에 대해 이야기하고 있습니다.
통합은 먼저 C API와 함께 Matlab, Mathematica와 함께 수행해야합니다.
GPU 기반 처리를 위해 제공되는 또 다른 기술은 기존 고급 계산 라이브러리의 GPU 버전입니다.그다지 화려하지는 않지만 이식 가능한 코드와 프로그래밍 용이성에 상당한 이점이 있습니다.
예를 들어, AMD의 Stream 2.0 SDK에는 GPU에서 일부 계산이 구현된 BLAS(선형 대수학) 라이브러리 버전이 포함되어 있습니다.API는 수년 동안 출시된 라이브러리의 CPU 전용 버전과 정확히 동일합니다.필요한 것은 애플리케이션을 다시 연결하는 것뿐입니다. 그러면 애플리케이션은 GPU를 사용하고 더 빠르게 실행됩니다.
마찬가지로 GTRI의 Dan Campbell은 신호 처리를 위한 VSIPL 표준의 CUDA 구현 작업을 진행해 왔습니다.(특히 레이더 시스템 및 의료 영상과 같은 관련 분야에서 일반적으로 사용되는 일종의 신호 및 이미지 처리입니다.) 다시 말하지만 이는 표준 인터페이스이며 다른 프로세서에서 VSIPL 구현을 위해 작성된 애플리케이션을 이 인터페이스로 간단히 다시 컴파일할 수 있습니다. 적절한 경우 GPU의 기능을 사용하십시오.
실제로 요즘에는 이미 상당수의 고성능 수치 프로그램이 자체 하위 수준 프로그래밍을 수행하지 않고 라이브러리에 의존합니다.Intel 하드웨어에서 숫자 계산을 수행하는 경우 일반적으로 Intel 수학 라이브러리(MKL)가 구현하는 대부분의 작업을 능가하는 것이 어렵습니다. MKL을 사용하면 모든 벡터 명령 및 코드를 전문화할 필요 없이 최신 x86 프로세서에서 영리한 트릭을 사용할 수 있습니다.GPU와 같은 것들을 사용하면 이것이 더욱 널리 퍼질 것이라고 생각합니다.
따라서 주목해야 할 기술은 비이식성 GPU의 양을 최소화하면서 효율적으로 GPU로 보낼 수 있는 알고리즘의 일부를 캡처하는 방식으로 특정 도메인의 애플리케이션을 위한 핵심 빌딩 블록을 형성하는 범용 라이브러리의 개발이라고 생각합니다. -프로그래머에게 요구되는 특별한 영리함.
(편향 면책조항:우리 회사에서는 VSIPL++ 라이브러리의 CUDA 포트도 작업하고 있으므로 이것이 좋은 생각이라고 생각합니다!)
또한 완전히 다른 방향으로 RapidMind가 수행하는 작업 중 일부를 확인하고 싶을 수도 있습니다.그들의 플랫폼은 처음에는 멀티코어 CPU 유형 시스템용으로 만들어졌지만 GPU 계산까지 확장하는 데 많은 노력을 기울여 왔습니다.
평행을 이룰 수있는 거의 모든 것이 혜택을받을 수 있습니다. 보다 구체적인 예는 Seti@Home, Folding@Home 및 기타 분산 프로젝트 및 과학 컴퓨팅입니다.
특히 부동 소수점 산술에 크게 의존하는 것들. 이는 GPU가 플로팅 포인트 작업에서 매우 빠른 특수 회로를 가지고 있기 때문입니다. 이것은 다재다능하지 않지만 그것이하는 일에 매우 능숙합니다.
더 전용 GPU 처리를보고 싶다면 확인하십시오. Nvidia의 Tesla GPU. GPU이지만 실제로 모니터 출력이 없습니다!
공통 데스크탑에서 GPU 처리가 너무 많거나 적어도 잠시 동안 보일 것입니다. 모든 사람이 CUDA 또는 유사한 유능한 그래픽 카드를 가지고 있지 않기 때문에 그래픽 카드가 전혀 없기 때문입니다. 또한 프로그램을보다 평행하게 만드는 것은 매우 어렵습니다. 게임은이 추가적인 힘을 활용할 수 있지만 모든 그래픽 계산이 대부분 GPU에 있고 다른 작업은 CPU 및 기타이기 때문에 매우 어려울 것입니다. 가지다 지침 세트로 인해 CPU에 있습니다.
적어도 한동안 GPU 처리는 많은 부동 소수점 계산이 필요한 매우 구체적인 틈새 시장에 적용됩니다.
직렬 일련의 작업조차도 여러 번 독립적으로 수행 해야하는 경우 병렬화로부터 혜택을받을 수 있다는 점을 명심해야합니다.
또한 누군가가 GPU 구현의 속도를 CPU 구현에보고 할 때마다 거의 공정한 비교가 아닙니다. 진정으로 공정하게하기 위해, 구현자는 먼저 진정으로 최적화 된 병렬 CPU 구현을 만들기 위해 시간을 소비해야합니다. 단일 인텔 코어 i7 965 XE CPU는 오늘날 약 70 기가 플롭을 이중 정밀하게 달성 할 수 있습니다. 현재 고급 GPU는 70-80 기가 플롭을 이중 정밀도로, 단일 정밀도로 약 1000을 수행 할 수 있습니다. 따라서 15 개 이상의 속도는 비효율적 인 CPU 구현을 암시 할 수 있습니다.
GPU 컴퓨팅의 중요한 경고 중 하나는 현재 "소규모"라는 것입니다. 슈퍼 컴퓨팅 시설을 사용하면 수백 또는 수천 개의 CPU 코어에서 병렬 알고리즘을 실행할 수 있습니다. 대조적으로, GPU "클러스터"는 현재 하나의 기계에 연결된 약 8 GPU로 제한됩니다. 물론, 이러한 기계들 중 일부는 함께 결합 할 수 있지만, 데이터는 컴퓨터 사이뿐만 아니라 GPU 사이에도 데이터가 전달되어야하므로 추가 복잡성을 추가합니다. 또한 아직 여러 시스템에서 여러 GPU로 투명하게 확장 할 수있는 MPI 동등한 점이 없습니다. 수동으로 구현해야합니다 (아마도 MPI와 함께).
이 규모의 문제 외에도 병렬 컴퓨팅을위한 GPU의 다른 주요 제한은 메모리 액세스 패턴에 대한 심각한 제한입니다. 임의의 메모리 액세스가 가능하지만 신중하게 계획된 메모리 액세스는 많은 성능을 향상시킵니다.
아마도 가장 유망한 다가오는 경쟁자는 인텔의 Larrabee 일 것입니다. CPU, 시스템 메모리 및 아마도 가장 중요한 캐싱에 대한 액세스가 상당히 높아집니다. 이것은 많은 알고리즘으로 상당한 이점을 제공해야합니다. 그러나 현재 GPU의 대규모 메모리 대역폭과 일치 할 수 없다면이 대역폭을 최적으로 사용하는 알고리즘 경쟁에 뒤떨어 질 수 있습니다.
현재 세대의 하드웨어 및 소프트웨어는 최적의 성능을 얻으려면 많은 개발자 노력이 필요합니다. 여기에는 종종 GPU 메모리를 효율적으로 사용하기위한 구조 조정 알고리즘이 포함됩니다. 또한 종종 최고의 접근 방식을 실험하여 최고의 접근 방식을 찾는 것도 포함됩니다.
또한 GPU 하드웨어 사용을 정당화하려면 최적의 성능을 얻는 데 필요한 노력이 필요합니다. 순진한 구현과 최적화 된 구현의 차이는 순서 이상이 될 수 있습니다. 이는 최적화 된 CPU의 고전화가 순진한 GPU 구현보다 우수하거나 더 좋을 것임을 의미합니다.
사람들은 이미 CUDA를 위해 .NET 바인딩을하고 있습니다. 보다 여기. 그러나 낮은 수준에서 일할 필요가 있기 때문에 GPU 컴퓨팅이 아직 대중을위한 준비가되어 있다고 생각하지 않습니다.
나는 오늘 GPU가 더 일반적인 목적 "배열 proceesor 유닛"으로 바꾸는 것에 대해 많은 이야기를 들었습니다. 어느 그래픽 처리가 아닌 매트릭스 수학 문제. 그래도 아직 많이 오지 않았습니다.
이론은 어레이 프로세서가 플로트 포인트 프로세서가 수십 년 전에 뒤 따르는 것과 거의 동일한 궤적을 따를 수 있다는 것이 었습니다. 원래 부동 소수점 프로세서는 많은 사람들이 구매를 귀찮게하지 않는 PC의 비싼 애드온 옵션이었습니다. 결국 그들은 너무 중요해서 CPU 자체에 넣었습니다.
GHC (Haskell) 연구원 (Microsoft Research에서 일하는)은 중첩 데이터 병렬 처리에 대한 지원을 범용 프로그래밍 언어에 직접 추가하고 있습니다. 아이디어는 백엔드에서 여러 코어 및/또는 GPU를 사용하지만 코드를 병렬로 실행하는 런타임 (또는 단일 CPU 폴백의 경우 직렬)에 관계없이 데이터 병렬 배열을 언어의 기본 유형으로 노출시키는 것입니다.
http://www.haskell.org/haskellwiki/ghc/data_parallel_haskell
향후 몇 년 동안이 성공에 따라 다른 언어 (C#)가 아이디어를 선택할 것으로 예상되며, 이는 이러한 종류의 기능을보다 주류 청중에게 가져올 수 있습니다. 아마도 그때까지 CPU-GPU 대역폭 및 드라이버 문제가 해결 될 것입니다.
GPU는 높은 수준의 문제에서 잘 작동합니다. 데이터 수준 병렬성, 이는 본질적으로 처리할 데이터를 모두 처리할 수 있도록 분할하는 방법이 있음을 의미합니다.
GPU는 본질적으로 클럭 속도 수준에서 그렇게 빠르지 않습니다.사실 저는 셰이더의 클럭 속도(혹은 요즘 GPGPU 용어가 더 많나요?)가 최신 데스크탑 프로세서의 ALU에 비해 꽤 느리다고 확신합니다.문제는 GPU가 엄청나게 많은 양의 셰이더를 가지고 있어 GPU를 매우 큰 셰이더로 만든다는 것입니다. 심드 프로세서.예를 들어 최신 Geforce의 셰이더 양을 사용하면 GPU가 한 번에 수백(수천?) 개의 부동 소수점 숫자를 처리하는 것이 가능합니다.
간단히 말해서, GPU는 데이터를 적절하게 분할하고 파티션을 독립적으로 처리할 수 있는 문제에 대해 놀라울 정도로 빠를 수 있습니다.그다지 강력하진 않아요 작업(스레드) 수준 병렬성.
GPU 기술의 큰 문제는 컴퓨팅 기능이 많지만 데이터를 얻는 것이 끔찍하다는 것입니다 (성능 면적). 비교 벤치 마크를주의 깊게 살펴보십시오 ... 종종 단일 프로세서 시스템의 GCC (최소 최적화, 벡터화)를 GPU와 비교합니다.
GPU의 또 다른 큰 문제는 데이터 구성 방식에 대해주의 깊게 생각하지 않으면 GPU에서 내부적으로 실제 성능을 겪게된다는 것입니다. 여기에는 종종 매우 간단한 코드를 복잡한 쓰레기 더미로 다시 작성하는 것이 포함됩니다.
이 기술에 대해 매우 흥분합니다. 그러나 나는 이것이 대역폭 중 하나 인 큰 병렬 작업의 실제 도전을 악화시킬 것이라고 생각합니다. 더 많은 코어를 추가하면 메모리에 대한 경합이 증가합니다. OpenCL 및 기타 GPGPU 추상화 라이브러리는이를 개선 할 수있는 도구를 제공하지 않습니다.
모든 고성능 컴퓨팅 하드웨어 플랫폼은 일반적으로 대역폭 문제로 하드웨어로 신중하게 계획되어 처리량, 대기 시간, 캐싱 및 비용을 균형을 잡습니다. 상품 하드웨어, CPU 및 GPU가 서로 분리되어 로컬 메모리에 최적화 된 대역폭으로 설계되면 필요한 알고리즘의 경우이를 개선하기가 매우 어려울 것입니다.
GPU가 여기에서 언급 한 것처럼 데이터 수준 병렬 처리 상황에서 매우 HI 성능 수를 달성 할 수 있다는 것은 사실입니다. 그러나 내가 알 수 있듯이, 지금은 사용자 공간에서 그것에별로 쓸모가 없습니다. 이 모든 GPGPU 선전은 GPU 제조업체에서 나온다고 느끼는 데 도움이 될 수 없습니다. GPU 제조업체는 새로운 시장과 제품을 찾고자합니다. 그리고 그것은 절대적입니다. 인텔/AMD가 왜 표준 코어 (예 : 4 개의 x86 코어와 64 개의 미니 X86 코어가있는 모델) 외에도 일부 미니 X86 코어를 포함하지 않은 이유를 궁금해 한 적이 있습니까? 그들은 원한다면 확실히 그렇게 할 수 있습니다. 내 생각에 업계는 일반 데스크탑/서버 시스템에서 그런 종류의 처리 능력이 필요하지 않다는 것입니다.
GPU는 현재만큼 인기가 없거나 남아 있지 않을 수도 있지만 기본 아이디어는 고전력 처리에 대한 다소 인기있는 접근 방식이되고 있습니다. 지금 등장하는 트렌드 중 하나는 CPU가 큰 부동 소수점 작업으로 돕는 외부 "가속기"입니다. GPU는 한 유형의 가속기 일뿐입니다.
인텔은 The라는 새로운 가속기를 출시하고 있습니다 Xeon Phi, 그들이 기대하고있는 것은 HPC 가속기로서 GPU에 도전 할 수 있습니다. 그만큼 셀 프로세서 일반적인 작업을 수행하기위한 하나의 주요 CPU를 갖고 다른 처리 요소에 집중 작업을 오프로드하여 인상적인 속도를 달성하는 비슷한 접근 방식을 취했습니다.
가속기는 일반적으로 현재 관심있는 것처럼 보이므로 적어도 한동안 주변에 있어야합니다. GPU가 사실상 가속기로 남아 있는지 여부는 여전히 남아 있습니다.
GPU가 CPU보다 빠르다는 인식은 PS3, NVIDIA 및 ATI 하드웨어에 적용되는 몇 가지 부활절한 병렬 응용 프로그램에 의해 생성 된 오해를 기반으로합니다.
http://en.wikipedia.org/wiki/embarrassly_parallel
대부분의 실제 과제는 이러한 유형의 작업으로 쉽게 분해 할 수 없습니다. 데스크탑 CPU는 기능 세트와 성능 관점에서 이러한 유형의 도전에 더 적합합니다.
CPU가 사용되는 것과 같은 것을 기대합니까?
나는 이것이 나에게 특성처럼 보인다는 것을 의미한다. 기술과 관련하여 "아무데도 갈 수 없다"고 주저하지만 GPUS 기본 기능은 그래픽 렌더링이고 CPU 1 차 기능은 다른 모든 처리입니다. GPU가 다른 일을하게하는 것은 단지 까다로운 것 같습니다.
