기고글 토론 "OpenCL: 기본에서 통찰력 있는 프로그래밍으로 향하여" - 페이지 2

 
denkir: 예를 들어 통계 계산을 추가할 수 있습니다.

이미 할 예정인데, (아마도) 대규모 기록에 대한 통계 수집이 될 것입니다. 하지만 움직임과는 아무 상관이 없습니다. 저는 무브가 싫어요 - 저는 할 권리가 있습니다 :)

따옴표 동기화.

이것은 GPU가 아닌 CPU를 위한 작업입니다. 모든 작업이 GPU에 적합한 것은 아니잖아요, 그렇죠? 적합한 것을 선택하는 것이 좋습니다. 그것이 GPU의 목적이기 때문입니다.

이것은 2차원 배열이 될 것입니다.

앞으로의 기사에서는 3 차원이 될 것이라고 가정합니다. 동시에 모든 차원의 배열을 표시하는 GPU 버퍼로 작업하는 방법이 명확해질 것입니다.

 
Mathemat:

이미이 작업을 수행하려는 경우 (대부분) 큰 이야기에서 통계를 수집하는 것일 것입니다.....

나는 미래의 기사에서 3 차원이 될 것이라고 가정합니다. 동시에 GPU 버퍼에 모든 차원의 배열을 작성하는 방법과 작업 방법이 명확해질 것입니다.

좋아요! 기다리자...

 
denkir: 터미널의 모든 상품에 대한 시세 내역을 가져옵니다. 1분 동안 시세를 동기화한다고 가정해 봅시다.

시세도 동기화해야 하나요?

추신: 도움말을 읽어보니 동기화가 필요하다는 것을 알았습니다.

 

하드웨어 업그레이드를 고려하여 기사의 결과를 다시 계산했습니다.

1년 전: 인텔 펜티엄 G840 CPU(2코어 @ 2.8GHz) + AMD HD4870 비디오 카드.

최근: CPU 인텔 제온 E3-1230v2(4코어/8스레드 @ 3.3GHz, i7-3770보다 약간 뒤처짐) + AMD HD 비디오 카드.6 870.

OpenCL의 계산 결과는 그래프에 표시됩니다(가로-기사에 적용된 최적화 횟수):


계산 시간은 초 단위로 세로로 표시됩니다. "CPU에서 한 번의 타격으로" 스크립트의 실행 시간 (OpenCL없이 하나의 코어에서)은 알고리즘 변경에 따라 95 초 이상 25 초 이내에 다양했습니다.

보시다시피 모든 것이 명확해 보이지만 여전히 명확하지는 않습니다.

명백한 외부인은 듀얼 코어 G840입니다. 글쎄, 그것은 예상되었습니다. 추가 최적화는 실행 시간을 크게 변경하지 않았으며 4 초에서 5.5 초까지 다양했습니다. 이 경우에도 스크립트 실행 가속도는 20배 이상의 값에 도달했습니다.

서로 다른 세대의 두 비디오 카드, 즉 구형 HD4870과 최신 HD6870 간의 경쟁에서 6870이 거의 승자라고 볼 수 있습니다. 고대 괴물 4870이 여전히 명목상의 승리를 거두었던 마지막 최적화 단계를 제외하고는 (거의 항상 뒤처졌지만). 솔직히 말해서 그 이유는 불분명합니다. 셰이더가 더 작고 빈도도 낮지만 여전히 이겼습니다.

이것이 여러 세대의 비디오 카드 개발의 변화라고 가정 해 봅시다. 또는 내 알고리즘의 오류 :)

나는 솔직히 모든 최적화에서 고대 4870보다 낫고 거의 동일한 조건에서 6870과 싸웠고 결국에는 그들 모두를 이길 수 있었던 Xeon에 만족했습니다. 모든 작업에서 항상 그렇게 될 것이라고 말하는 것은 아닙니다. 그러나 이 작업은 계산적으로 매우 어려웠습니다. 결국 2000 x 2000 크기의 두 행렬을 곱하는 것이었기 때문입니다!

결론은 간단합니다. 이미 i7과 같은 적절한 CPU가 있고 OpenCL 계산이 너무 길지 않다면 추가 강력한 히터 (비디오 카드)가 필요하지 않을 수 있습니다. 반면에 수십 초 동안 (긴 계산 중에) 돌을 100%로로드하는 것은 컴퓨터가이 시간 동안 "응답 성을 잃기"때문에 그다지 즐겁지 않습니다.

 

안녕하세요,

OpenCL이 EveryTick 모드에서 EA 백테스팅 속도를 어떻게 높일 수 있는지 예를 들어 설명해 주시겠습니까? 현재 EveryTick 모드에서 14년 데이터를 실행하는 데 18분이 걸립니다. OpenCL로 테스트 시간을 50% 단축할 수 있다면 많은 트레이더가 관심을 가질 것이라고 생각합니다.

 

훌륭한 기사, 나는 루프 내부에서 개인 메모리로 행의 전송을 외부로 이동하는 것이 어떻게 속도를 높이는 지 이해하지 못했습니다.

어쨌든 동일한 전송 작업이 발생하지만 내 코드에는 아무런 영향을 미치지 않지만 물론 각 경우가 다릅니다. (그러나 무언가를 추가 한 후 다시 0 영향은 속도가 빨라졌지만 이득이 없음을 의미합니다).

OpenCL 소스에서 이 부분 :

      "  REALTYPE rowbuf[ COLSROWS ];                                               \r\n"
      "  for( int col = 0; col < COLSROWS; col ++ )                                 \r\n"
      "     rowbuf[ col ] = in1[ r * COLSROWS + col ];                              \r\n"

크런치 루프 외부로 이동하는 곳

고마워요

 
기사 주셔서 감사합니다. 큰 도움이 되었으며 실습에 적용하기를 기대합니다.