OpenCL의 미래?


22

OpenCL 프로그래밍 패러다임은 이기종 컴퓨팅을위한 로열티없는 개방형 표준이 될 것입니다. OpenCL 기반의 소프트웨어 개발에 시간을 투자해야합니까? 찬반 양론?


CUDA에서는 더 열심히 코딩 할 수 있습니다. OpenCL은 구조체 만 지원하는 C ++ 클래스가 있습니다. CUDA는 조금 더 성숙합니다. 고급 기능이 필요하지 않으면 OpenCL로 전환합니다.
vanCompute

답변:


19

이 질문은 너무 광범위하고 모호하여 실제로 대답 할 수 없습니다. 그러나 과학 컴퓨팅의 관점에서 OpenCL에 대한 주목할만한 점은 거의 강조되지 않습니다. 지금까지 OpenCL을위한 오픈 소스 인프라 라이브러리를 만들려는 노력은 없었지만 CUDA에는 몇 가지 훌륭한 옵션이 있습니다.

채택의 주요 촉진자가 고품질의 공개 라이브러리이기 때문에 이것이 OpenCL에 실제로 해를 끼칠 것이라고 생각합니다.


3
흥미로운 점; 특히 CUDA 컴파일러 자체에 대한 라이센스가 전혀 공개되지 않았기 때문에 (이 사람들이 맨 위에 구축한다고 가정합니다.) 완전 오픈 소스 OpenCL 솔루션을 개발하고자하는 사람 ...
Erik P.

2
@JackPoulson 나는 OpenCL 라이브러리가 부족하다는 사실에 대해 신비하지만 CUDA 이유는 분명합니다. 그들은 훌륭한 인재를 고용하고 유용한 도서관을 개발하는 데 실제로 자원을 투입했습니다.
Matt Knepley

6
라이브러리는 빠르게 태어나고 죽습니다. 표준은 오랫동안 고통 스럽습니다.
mbq

6
ViennaCL 간과되어서는 안된다.
Aron Ahmadia

4
@mbq Scientific 라이브러리는 수명이 길고 사고뿐만 아니라 연습에도 큰 영향을 미칩니다. 증인 CHARMM, BLAS, RELAP, GEANT 등
Matt Knepley

16

OpenCL 대 무엇?

질문이 OpenCL vs CUDA라면이 질문에 대해 많은 수고를 겪는 것을 보았습니다. 중요하지 않습니다. 정직한. 모든 어려운 생각을해야하는 커널은 두 언어 사이에서 실질적으로 동일합니다. OpenCL과 CUDA간에 바운스 작업의 99 %를 수행하도록 좋아하는 편집기에 대한 매크로를 작성할 수 있습니다. 그런 식이어야합니다. 그것들은 궁극적으로 매우 유사한 종류의 하드웨어를 저수준으로 제어합니다. {OpenCL, CUDA}에서 중요한 커널을 작성하는 방법을 알아 낸 후에는 {CUDA, OpenCL}로 포팅하는 것이 간단합니다.

작성해야하는 상용구 호스트 코드도 비슷하지만 CUDA는 간단한 경우를 간단하게 유지합니다. 우리가 센터에서 CUDA를 가르치는 이유입니다. 커널 코드를 작성하는 데 뛰어들 수 있지만, OpenCL을 위해 커널을 시작하는 과정을 설명하는 데 하루 종일 1-2 시간을 소비해야합니다.

그러나 차이점조차 그렇게 중요하지 않습니다. 더 복잡한 일을 시작하면 (여러 GPU에서 비동기 커널), 둘 다 똑같이 복잡하고 다시 한 줄에서 다른 줄로 번역 할 수 있습니다.

OpenCL과 지시문 기반 접근 방식 ( OpenACC 또는 HMPP 또는 기타)이 미래에 이러한 종류의 아키텍처를 프로그래밍하는 좋은 방법이 될 것입니다. 작업의 10 % 그러나 어떤 선택이 "승리"를해야하는지에 대해서는 아직 많은 사람들과 함께 일하는 것은 권장하지 않습니다.

CUDA 또는 OpenCL 사이에서 편리한 언어를 선택하여 사용하면 걱정할 필요가 없습니다. 메모리가 거의없는 작은 코어를 위해 대규모 병렬 SIMD 코드로 문제를 분해하는 방법을 알아내는 귀중한 부분은 프로그래밍 모델간에 쉽게 이식 할 수 있습니다.

NVIDIA 하드웨어를 사용하고 있다면 아마도 CUDA를 추천합니다. 라이브러리에 대한 Matt Knepley의 지적은 끝났습니다. 그렇지 않다면 OpenCL입니다.


1
유일한 차이점은 커널이며 커널은 동일하지만 상용구가 더 간단하기 때문에 CUDA를 사용한다고 말합니다. CUDA의 상용구가 더 단순하다는 데 동의하지만 OpenCL 상용구를 도울 수있는 라이브러리 ( 예 : code.google.com/p/clutilgithub.com/hughperkins/OpenCLHelper)가 있습니다 (면책 조항 : OpenCLHelper는 제 자신입니다)
Hugh Perkins

7

OpenCL을 기반으로 소프트웨어를 개발하는 데 시간을 투자해야하는지 여부는 귀하 만 대답 할 수 있습니다. 지금 당면한 문제를 해결할 가능성이 있고 다른 열린 솔루션이없는 경우 가장 좋은 방법은 소규모 프로젝트를 구현하는 데 위험을 초래하는 것입니다.

그것이 잘된다면, 당신은 그것을 표준화 할만 큼 충분한 자신감을 쌓거나 다른 솔루션 (자신의 독점적 인 솔루션, 다른 열린 솔루션 또는 다른 독점 솔루션).

오픈 소스 운동에 대한 멋진 일이 있기 때문이다 원본이 당신이 모든 것을 가지고 당신이 필요한 경우 프로젝트를 포크 할 필요가있다. 커뮤니티 자체가 필요한 시설을 제공하지 않더라도 해당 시설을 스스로 구현하는 것을 막을 수있는 것은 없습니다. 또한 이러한 기능을 원한다면 다른 사용자가 원하는 기능을 사용할 수있는 가능성이 있으므로 이러한 변경 사항을 핵심 프로젝트에 다시 제공하면 감사하겠습니다.

뿐만 아니라 자신의 관점에서 더 나아질 경우 다른 사람들에게 더 나아질 수 있으며, 자신의 개선 사항을 제출하도록 권장하고 궁극적으로 모든 사람을 위해 소프트웨어를 개선 할 수 있습니다.

마지막으로, 이것은 일반적인 질문에 대한 일반적인 답변입니다. 더 자세히 대답하려면 OpenCL에 대한 귀하의 우려가 무엇인지 알아야합니다. 성숙합니까? 커뮤니티 지원? 사용의 용이성? 배우는데 시간이 필요한가요? 개발할 시간? 절차 변경? 장단점에 대해 질문 할 때 OpenCL다른 제품비교 하려는 다른 제품 은 무엇입니까? 어떤 연구를 이미 했습니까? 이기종 컴퓨팅 환경을 지원하려면 어떤 기능이 필요합니까?


6

하나의 큰 PRO는 OpenCL 뒤에있는 공급 업체의 수입니다. 엔비디아 구동 시스템을 위해 상당히 복잡한 CUDA 코드를 개발하는 데 많은 시간과 노력을 들인 연구 그룹을 만난 것에 대한 일화적인 경험이 있습니다. 1 년 후 코드가 개발 된 후 리서치 그룹은 더 크고 더 빠른 AMD 기반 시스템에 액세스 할 수 있었지만 코드를 이식 할 (인적) 자원이 없기 때문에이를 사용할 수 없었습니다.

CUDA와 OpenCL의 핵심 기능이 거의 동일하더라도 (@JonathanDursi가 잘 지적했듯이) 원래 개발자가 코드 변환 작업에 할당 된 개발자가 아닌 경우 전체 포팅 프로젝트는 시간이 많이 걸릴 수 있습니다.

그러나 CUDA와 OpenCL 간에는 공식적인 비 호환성이 있습니다. 가장 현저하게 CUDA는 c ++ 템플릿을 지원하지만 OpenCL은 아직 공식적으로 지원하지 않습니다. 그러나 AMD는 템플릿 및 기타 C ++ 기능을 지원하는 OpenCL의 확장 기능을 개발하기 위해 노력하고 있으며, 이 게시물에서 AMD dev central의 자세한 정보를 얻을 수 있습니다. 향후 OpenCL 개정판에이 작업이 추가되기를 바랍니다.

이 시점 (2012 년 초)에 @MattKnepley가 링크하는 멋진 라이브러리는 비공개 소스이거나 템플릿을 사용하므로 최소한 그 동안 NVIDIA 이외의 하드웨어에서는 사용할 수 없습니다.

GPU 컴퓨팅을 배우는 사람에게는 OpenCL C가 기본 아이디어에서 학습자를 혼란스럽게하는 세부 정보가 많기 때문에 CUDA가 더 간단하고 간단하기 때문에 OpenCL C가 매우 어려울 수 있다고 말합니다. 그러나 모든 파이썬 설탕을 OpenCL로 가져 오는 PyOpenCL (opencl의 파이썬 래퍼)과 같이 OpenCL을 배우고 사용하기가 훨씬 쉬운 도구가 있습니다 (PyCUDA도 있음). 예를 들어, 두 개의 어레이를 추가하기위한 PyOpenCL 데모는 25 줄 미만이며 호스트 및 장치에서 어레이 생성, 데이터 전송, 컨텍스트 및 대기열 생성, 커널, 커널 구축 및 실행 방법을 포함합니다. GPU에서 결과를 가져 와서 numpy와 비교합니다 (아래 링크 참조).

PyOpenCL - http://mathema.tician.de/software/pyopencl

PyCUDA - http://mathema.tician.de/software/pycuda

숙련 된 GPU 프로그래머에게는 @JonathanDursi에 동의합니다 .CUDA와 OpenCL은 기본적으로 동일하며 시장 차이는 없습니다. 더욱이, GPU를위한 효율적인 알고리즘을 개발하는 노력은 언어와 무관하며 공급 업체와 문서의 OpenCL 지원은 2 년 전보다 훨씬 더 성숙해졌습니다. 여전히 차이를 만드는 유일한 점은 NVIDIA가 CUDA 커뮤니티에 대한 지원으로 실제로 큰 일을하고 있다는 것입니다.

OpenCL은 CPU에서 실행할 수 있고 Intel 및 AMD에서 이미 지원한다는 이점이 있습니다. 따라서 사용 가능한 CPU 코어를 활용하려는 경우 알고리즘 프레임 워크를 변경할 필요가 없습니다. CPU 최적화 커널이 GPU 최적화 커널과 크게 다르게 보일 수 있기 때문에 OpenCL이 단일 CPU / 멀티 코어 지향 응용 프로그램에 가장 적합한 솔루션이라고 생각하지 않습니다. 그러나 내 경험상 CODE 개발은 CPU에서 실행할 수 있다는 이점이 있습니다.


5

OpenCL은 현재 "챔피언"부족으로 고통 받고 있다고 생각합니다. 예를 들어, 지금 NVIDIA 사이트를 방문하면 (2011 년 12 월 16 일) 스플래시 페이지에서 GPU 컴퓨팅의 과학 / 산업 측면에 중점을 둔 "Ken Burns Effect"스타일 샷이 여러 개 있으며 ~ 1 / 네 번째 탐색 옵션은 CUDA에서 끝날 수있는 것들을 가리 킵니다. "GPU 컴퓨팅"서버 및 워크 스테이션을 판매하는 제조업체는 NVIDIA 솔루션을 판매합니다.

ATI의 경쟁 제품은 일반 AMD 사이트와 혼합되어 있으며 찾기가 어렵고 타사 솔루션에는 그다지 중요하지 않습니다. 이러한 솔루션과 OpenCL 기반 프로그래밍을 수행 할 수있는 능력은 확실히 존재하지만, 적어도 내 마음에는 있지만 다른 사람들의 생각에는 OpenCL 플랫폼의 대기업 스폰서가 이미 " 필드를 종료하십시오. " 예를 들어 OS X를 사용하는 사람들은 OpenCL GPU 컴퓨팅을 추진하기 위해 1 년 안에 Apple 워크 스테이션이 존재할지 여부에 대해 너무 바빠서 생각할 것입니다.


4

가장 중요한 요소는 CUDA가 NVIDIA 하드웨어에서만 지원된다는 것입니다.

따라서 강력하고 이식 가능한 소프트웨어를 만들려면 OpenCL이 유일한 옵션입니다. 현재 CUDA 기반 라이브러리를 구축 할 수 있으며 향후 OpenCL을 통해 코드를 확장 할 수 있기를 바랍니다.


전혀 명확하지 않습니다. 많은 사람들이 그 표준을 채택한 후에 공개 된 독점 표준이 있습니다.
Matt Knepley

@MattKnepley NVIDA조차도 CUDA를 표준으로 강제하지 않습니다. 말할 것도없이, OpenCL과 기본적으로 동일한 것으로 끝날 것입니다.
mbq

1
실제로는 그 반대 일 것입니다. OpenCL은 CUDA의 모든 멋진 것들 (대부분 이미 존재하는 곳, 어디에서 왔는지 생각하십니까?)을 채택하고 더 이상 불쾌한 것들을 제거하게 될 것입니다.
Matt Knepley
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.