OpenCL: 실제 문제 - 페이지 6

[Roffild]

Mathemat : 아직 테스터에서 테스트하지 않았습니다.

그럼 왜 확인되지 않은 헛소리를 게시 했습니까?

아직 테스터에서 OpenCL을 사용한 사람은 나뿐인 것 같은데... 시도했는데...

[Sceptic Philozoff]

Roffild :

그럼 왜 확인되지 않은 헛소리를 게시 했습니까?

아직 테스터에서 OpenCL을 사용한 사람은 나뿐인 것 같은데... 시도했는데...

말도 안되는 소리가 아니라 만족스러운 어플입니다.

다시 한 번: 서비스 데스크에 글을 쓰고 원하는 것을 정당화하십시오. 정당화할 수 없다면 그것은 당신의 문제입니다.

이 글을 쓰는 시점에서 테스터에서 OpenCL을 사용하는 것에 대한 대화는 아직 본격적으로 시작되지 않았습니다. 애플리케이션은 이 시간을 참조합니다.

0.35300ms 는 커널 내부의 전역 메모리 액세스가 아니라 clEnqueue[Read/Write]Buffer ()를 특별히 참조하기 때문에 두뇌를 켜야 합니다.

이 명령은 MQL5용 OpenCL 구현에 존재하지 않습니다. 무슨 얘기를 하는 건가요?

[Vladimir Gomonov]

Roffild :

내 게시물을 다시 읽으십시오.

주요 기준: 1틱 동안 "OpenCL 스타일"의 MQL 코드 실행은 시간 = Number_of_Buffers * 0.35300ms 를 초과해야 합니다.

마이크로초(1000마이크로초 = 1밀리초)의 정확도로 MQL에서 알고리즘의 속도를 알아내려면 테스터와 Total_Time/Number_Ticks(내 최고 게시물)에서 여러 번 실행해야 합니다.

버퍼 지연이 아닌 경우 내 코드는 ~30초 만에 테스트를 통과했습니다. 이는 MQL "OpenCL 스타일"(55초)보다 ~2배, 일반 코드(320초)보다 ~11배 빠릅니다.

다른 기준은 무엇입니까?

글쎄, 나는 모든 것을 내려 놓고 다시 읽을 것입니다. OpnCL에 관한 포럼의 모든 게시물을 다시 읽으라고 요청하는 것이 아닙니다. :) 그리고 그 사이에 모든 주요 기준이 설명되고 논의됩니다.

주요 기준은 t_alg/t_mem 비율입니다. 여기서 t_alg는 커널 알고리즘을 계산하기 위해 알고리즘적으로 최적화된 시간이고, t_mem은 원격(*) 메모리에 액세스하는 시간입니다. 이 기준이 클수록 OpenCL을 사용하여 가속화할 가능성이 커집니다. 다시 말해서, 계산이 "무거워질수록" 어레이와 장치로의 어레이 전송이 적을수록 더 유망합니다.

(*) 원격 메모리 = 모든 종류의 "등록되지 않은" 메모리(등록된 것은 매우 빠름), 예를 들어 (1) 전역 장치 메모리는 등록된 메모리보다 훨씬 느리지만 (2) 장치 외부 메모리(프로세서 RAM ).

[Roffild]

Mathemat :

말도 안되는 소리가 아니라 만족스러운 어플입니다.

다시 한 번: 서비스 데스크에 글을 쓰고 원하는 것을 정당화하십시오. 정당화할 수 없다면 그것은 당신의 문제입니다.

다시 한 번: 버그 #865549( 2013.10.17 23:17) 및 개발자에게 알림이 전송되었지만 수정될 가능성은 거의 없습니다. 아마도 그들 중 하나는 최적화 중에 전체 프로세서를 일시 중단하지 않도록 이 제한을 특별히 추가했을 것입니다.

그러나 기사에는 이것에 대한 단어가 없습니다!

수학 :

0.35300ms 는 커널 내부의 전역 메모리 액세스가 아니라 clEnqueue[Read/Write]Buffer ()를 특별히 참조하기 때문에 두뇌를 켜야 합니다.

이 명령은 MQL5용 OpenCL 구현에 존재하지 않습니다. 무슨 얘기를 하는 건가요?

어 ... 그리고 당신은 OpenCL에 대한 기사를 제공합니다 ...

clEnqueueReadBuffer = CLBufferRead 및 clEnqueueWriteBuffer = CLBufferWrite이며 동기식으로 호출되기도 합니다.

지식은 여기에서 시작됩니다

MetaDriver : 주요 기준은 t_alg/t_mem 비율입니다. 여기서 t_alg는 커널 알고리즘을 계산하기 위한 알고리즘 최적화 시간이고 t_mem은 원격(*) 메모리에 액세스하는 시간입니다. 이 기준이 클수록 OpenCL을 사용하여 가속화할 가능성이 커집니다. 다시 말해서, 계산이 "무거워질수록" 어레이와 장치로의 어레이 전송이 적을수록 더 유망합니다.

이것은 성능 최적화 기준일 뿐입니다. 내 게시물 이전에는 버퍼 자체의 전송 속도에 대한 대략적인 수치가 없었습니다.

[Roffild]

사람들은 무언가를 더 증명하기 전에 다음과 같이 생각합니다. 여기에서 시작하는 세 개의 게시물에 대해 구체적으로

mql5 : 특히 이 예에서 OpenCL을 사용하는 이점은 버퍼를 복사하는 오버헤드에 의해 소모됩니다.

그런 다음 커널 자체 최적화에 집착하고 내 게시물은 버퍼에 관한 것입니다.

[Sceptic Philozoff]

Roffild : 아시다시피 clEnqueueReadBuffer = CLBufferRead 및 clEnqueueWriteBuffer = CLBufferWrite이며 동기식으로 호출되기도 합니다.

저는 MQL5용 OpenCL 구현이 진정한 API에 대한 래퍼라는 것을 오랫동안 알고 있었습니다. 그런데 두 번째 글에서는 워킹그룹(work-group)의 규모를 정할 기회가 충분하지 않다고 썼다. 나는 서비스 데스크에 요청했고 잠시 후 그들은 그것을했습니다.

나는 또한 CLBuffer[Read/Write]가 clEnqueue [Read/Write]Buffer와 유사하다는 것을 알고 있지만 이러한 기능은 전혀 동일하지 않습니다.

하지만 왜 MQL5용 OpenCL에서 사용할 수 없는 clEnqueueXXX 기능 에 대해 계속 이야기하는지 이해가 되지 않습니다.

나는 당신이 원하는 것을 알아 내려고 노력할 것입니다.

로프필드 :

0.35300ms 는 커널 내부의 전역 메모리 액세스가 아니라 clEnqueue[Read/Write]Buffer ()를 특별히 참조하기 때문에 두뇌를 켜야 합니다.

두 번째는 커널 자체를 최적화하여 해결되지만 첫 번째는 철의 한계 이며 여기서 두뇌가 도움이 되지 않습니다.

좋은. 주장은 누구입니까? 비디오 카드 제조업체에?

[Roffild]

Mathemat : CLBuffer[Read/Write]는 clEnqueue[Read/Write]Buffer와 유사하지만 이러한 기능은 전혀 동일하지 않으며 구문이 다릅니다 .

하지만 왜 MQL5용 OpenCL에서 사용할 수 없는 clEnqueueXXX 기능 에 대해 계속 이야기하는지 이해가 되지 않습니다.

예, 차이가 없습니다. 아마 다음과 같은 것이 있을 것입니다:

 template < typename T>
cl_int BufferWrite(cl_mem buffer, const T *ptr)
{
        size_t bufsize;
        errcode = clGetMemObjectInfo(buffer, CL_MEM_SIZE, sizeof (bufsize), &bufsize, 0 );
         return (errcode = clEnqueueWriteBuffer(enqueue, buffer, CL_TRUE, 0 , bufsize, ptr, NULL , NULL , NULL ));
}
template < typename T>
cl_int BufferRead(cl_mem buffer, T *ptr)
{
        size_t bufsize;
        errcode = clGetMemObjectInfo(buffer, CL_MEM_SIZE, sizeof (bufsize), &bufsize, 0 );
         return (errcode = clEnqueueReadBuffer(enqueue, buffer, CL_TRUE, 0 , bufsize, ptr, NULL , NULL , NULL ));
}

따라서 구문에 대해 발명할 수도 없습니다. 그리고 세 번째 인수 = CL_TRUE가 이미 확인되었습니다.

수학 :

두 번째는 커널 자체를 최적화하여 해결되지만 첫 번째는 철의 한계 이며 여기서 두뇌가 도움이 되지 않습니다.

좋은. 주장은 누구입니까? 비디오 카드 제조업체에?

이 가장 중요한 제한 사항에 대한 실질적인 데이터가 없다는 주장은 특히 기사 작성자에게 있습니다! (내가 테스트하기 전까지는.)

[Vladimir Gomonov]

Roffild :

이 가장 중요한 제한 사항에 대한 실질적인 데이터가 없다는 기사 작성자의 주장입니다! (내가 테스트하기 전까지는.)

더 이상 기사를 읽지 마십시오. 그리고 불만은 없을 것입니다. ;)

--

뭐하는거야? 기사에서 알 수 없는 데이터를 어떻게 제공할 수 있습니까? 장치에서 / 장치로의 데이터 전송 지연이 크고 포럼에서 두 번 이상 고려되어야한다는 사실. 특정 수치는 특정 장비에 따라 다릅니다. 글쎄, 나는 그것을 스스로 테스트했고 잘했다. 저를 포함한 사람들은 때때로 다양한 하드웨어의 기능과 한계를 평가하기 위해 테스트 코드를 게시합니다. 그들은 다른 사람들에게 결과를 공유하도록 요청하고, 사람들은 종종 그것을 수행합니다(그들이 존경받는 이유). 동시에 모든 사람이 통계를 보고 어떤 조합에서 효과가 있는지 확인합니다. 그런 다음 결과에 중점을 둔 누군가가 하드웨어를 재구매하거나 코드 작성 방식을 변경합니다. 그리고 너, 젠장... 뭘 원해? 글쎄, Sportloto에 불만을 작성하십시오. 아마도 코드가 더 빨리 작동하게 될 것입니다 ...

:)

[Roffild]

사실, 나는 이미 https://www.mql5.com/ru/forum/13715/page5#comment_646513 에서 모든 것을 마쳤 지만 기사의 저자는 다른 것을 증명하고 싶었습니다.

귀하의 기사에는 구체적이고 매우 중요한 정보가 없으므로 완료되지 않고 비현실적인 작업을 설명합니다.

기사에 정보를 추가할 수는 없지만 이 숫자가 아무 의미가 없는 척하는 것은 어리석은 일입니다.

[Sceptic Philozoff]

당신이 게시 한 대본 / 고문 Roffield 의 숨겨진 의미를 이해하지 못했습니다. 코드는 쉽게 말해서 오해입니다.

- cl_khr_fp64 pragma는 어디에 있습니까? 커널에서 double로 계산할 때 필요합니다.

- 일반적으로 한 번 계산된 초기 초기화로 이동할 수 있는 OnTick() 함수 에 이 코드 조각이 있는 이유는 무엇입니까?

 uint units = ( uint ) CLGetInfoInteger (hcontext, CL_DEVICE_MAX_COMPUTE_UNITS );
uint global_work_offset[] = { 0 };
uint global_work_size[ 1 ];
uint local_work_size[ 1 ];
global_work_size[ 0 ] = ArraySize (price);
local_work_size[ 0 ] = global_work_size[ 0 ] / units;

- 전역 작업 크기가 240바이트인 이유는 무엇입니까? OpenCL의 이점을 얻으려면 훨씬 커야 합니다. 글쎄, 적어도 백만 번 - 눈으로 추정한다면.

- 로컬 작업의 크기를 얻기 위해 전역 작업을 단위 수로 나눈 이유는 무엇입니까? CPU와 GPU 모두 전역 작업을 훨씬 더 많은 수의 하위 작업으로 나눌 수 있습니다. 그리고 귀하의 경우 단위는 SIMD 엔진의 수입니다.

예를 들어 비디오 카드의 장치 수는 28개(Radeon HD7950)입니다. 그러나 이 숫자는 240을 정확히 나누지 않습니다. 이는 계산의 상당 부분이 병렬이 아닐 수 있음을 의미합니다.

내가 가지고 있는 셰이더의 수는 1792이고 당신의 셰이더는 1440입니다. 맵을 정상적으로 로드하려면 전역 작업을 이 숫자로 나누는 것이 좋습니다. 그러나 전역 작업의 크기를 올바르게 계산해야 합니다. (그리고 나누지 않고 곱하는 것이 좋습니다.)

그리고 당신의 카드가 지금까지 생각하는 것은 전혀 명확하지 않습니다.

간단히 말해서: 당신의 코드는 무엇을 해야 합니까?