OpenCL: MQL5의 내부 구현 테스트 - 페이지 4

 
WChas :
내가 올바르게 이해했다면 1 GPU가 하나의 매우 강력한 에이전트입니까? 이 경우 프로세서 에이전트를 비활성화할 수 있습니까(비디오와 관련하여 속도가 낮기 때문에)? 그리고 반복합니다: 교차 사격 없이 두 개의 ATI를 가질 수 있습니까?

AMD는 OpenCL에 Crossfire를 사용하는 것을 강력히 권장하지 않습니다. Crossfire에는 실제로 두 개의 GPU가 있지만 CAM 드라이버는 하나의 그래픽 작업을 둘 사이에 나누기 때문입니다. 반대로 OpenCL 1.1의 경우 비디오 카드 드라이버가 두 GPU 간에 하나의 OpenCL 작업을 공유할 수 있는 방법이 아직 없습니다(위 참조).

엔비디아 SLI도 마찬가지입니다.

 

OpenCL을 포함하면 클라우드 컴퓨팅 비용에 어떤 영향을 미칩니까?

GPU가 있는 에이전트의 비용은 GPU가 없는 에이전트의 비용보다 높을 것입니다. 첫 번째 상담원의 예상 시간이 훨씬 더 단축됩니까?

로컬 머신에 있는 하나의 에이전트에만 GPU가 제공된다는 사실을 고려할 때 동일한 로컬 머신에 있는 서로 다른 에이전트의 비용이 다를 것이라는(미리 계산된) 의미입니까?

 
hrenfx :

OpenCL을 포함하면 클라우드 컴퓨팅 비용에 어떤 영향을 미칩니까?

GPU가 있는 에이전트의 비용은 GPU가 없는 에이전트의 비용보다 높을 것입니다. 첫 번째 상담원의 예상 시간이 훨씬 더 단축됩니까?

로컬 머신에 있는 하나의 에이전트에만 GPU가 제공된다는 사실을 고려할 때 동일한 로컬 머신에 있는 서로 다른 에이전트의 비용이 다를 것이라는(미리 계산된) 의미입니까?

"작업을 실행할 때 테스트 에이전트 가 수행한 작업은 소요된 시간에 대한 PR의 산물로 고려됩니다."
 
저는 OpenCL 1.0에 대해 혼동하지 않습니다. 드라이버와 관련된 심각한 문제를 배경으로 두 배로 사용하려면 정말 위험해야 합니다. 실제로 오래된 드라이버가 감지되면 터미널은 최신 버전으로 업그레이드해야 한다는 메시지와 함께 OpenCL 사용을 비활성화합니다 . 그렇지 않으면 가장 무해한 작업에서도 끊김이 불가피합니다.

기본적으로 시작 시 터미널/에이전트는 기능 집합에 따라 가장 강력한 GPU 장치를 선택합니다. 지금까지는 MQL5에서 장치를 선택할 생각이 없습니다. 이는 코드를 복잡하게 만들고 추가 오류를 유발할 뿐입니다.

대신 각 물리적 GPU를 개별 에이전트에 자동으로 배포하여 잠재력을 최대한 활용할 수 있도록 하는 형태로 더 아름다운 아이디어가 있습니다.
 

GPU가 없는 에이전트보다 GPU가 있는 에이전트에서 20배 더 빠르게 최적화하는 EX5(OpenCL 사용)가 있다고 가정해 보겠습니다.

클라우드에서 최적화를 시작합니다 . 분명히 물리적 GPU가 있는 에이전트에서 최적화를 먼저 실행하는 것이 (소요 시간 측면에서) 더 유리합니다. 그들에게 대부분의 검색 옵션을 제공합니다. 이는 PR이 20배 더 높은 것과 같습니다. 그러나 GPU를 사용하지 않고 PR은 동일합니다. 저것들. 새로운 PR - PR_gpu의 계산을 입력해야 합니다.

Mischek :
" 작업을 실행할 때 테스트 에이전트가 수행한 작업은 소요 시간에 따라 PR의 산물로 고려됩니다."

이 공식에 따르면 PR_gpu가 없으면 GPU가 있는 클라우드의 모든 최적화 비용이 GPU가 없는 경우보다 저렴합니다.

불행히도 대체 PR 계산의 도입 - 최적화된 EX5 파일의 단일 테스트 패스에는 보편적인 사용이 불가능한 수많은 함정이 포함되어 있습니다.

 
hrenfx :


이 공식에 따르면 PR_gpu가 없으면 GPU가 있는 클라우드의 모든 최적화 비용이 GPU가 없는 경우보다 저렴합니다.

불행히도 대체 PR 계산의 도입 - 최적화된 EX5 파일의 단일 테스트 패스에는 보편적인 사용이 불가능한 수많은 함정이 포함되어 있습니다.

제가 잘 모르는 부분은 짚고 넘어가지 않고, 실제 PR을 수정하지 않으면 GPU로 클라우드에 넘기는 것은 의미가 없습니다.

또한 새로운 개념을 도입하고 마음에 들면) 예를 들어 에이전트 비용 을 즉시 정의하는 것이 좋습니다. 그렇지 않으면 이 경우 사용자 측을 말하는 것으로 추측해야 합니다.

 

현재 PR = Const Koef / 참조 작업에 소요된 시간 .

최적화 비용은 최적화가 지속되는 동안 계산할 수 있는 참조 작업의 수와 같습니다. 저것들. 계산 비용은 클라우드가 에이전트 간에 작업을 분산하는 방식에 따라 달라지지 않습니다. 그러나 최적화의 최종 기간은 가장 중요한 지표인 정확한 분포에 달려 있습니다.

클라우드는 예상 시간을 줄이기 위해 미리 계산된 PR에 비례하여 에이전트 간에 작업을 분배하는 것이 분명합니다(그러나 비용은 줄이지 않음 - CONST).

 
물론 실제 GPU 사용량으로 자동으로 PR을 올려드립니다. 하지만 먼저 공개 테스트용 베타를 출시합시다.

물론 OpenCL을 사용한 작업은 처음에 적절한 GPU를 가진 에이전트에게 주어집니다.
 
hrenfx :

계산 비용은 클라우드가 에이전트 간에 작업을 분산하는 방식에 따라 달라지지 않습니다.

불행히도 대체 PR 계산의 도입 - 최적화된 EX5 파일의 단일 테스트 패스에는 보편적인 사용이 불가능한 수많은 함정이 포함되어 있습니다.

옵티마이저의 비용은 항상 일정하지만 기간은 PR의 적절한(이 작업에 대한) 계산에 크게 의존하기 때문에 양심에 따라 EX5 PR_calculate의 코드에 최적화 입력을 도입할 가치가 있습니다. 옵티마이저는 자신의 알고리즘 기능을 기반으로 자신의 작업에 가장 적합한 분배 PR의 계산을 스스로 설정합니다.

예를 들어, 작업이 순전히 계산적이라면 PR_calculate에서 강조점은 수학에 있을 것입니다.

작업이 엄청난 양의 데이터를 넘기는 경우 - 메모리 작업 속도로.

GPU를 약간 사용하는 경우 PR_calculate에 이를 표시합니다.

GPU가 EX5의 모든 곳에서 사용되는 경우 - 적절한 PR_calculate를 작성하십시오(적절한 GPU 사용으로).

이 방식으로 클라우드에 전력을 기부하는 사람들은 확실히 아무것도 잃지 않으며, 전력을 사용하는 클라우드는 계산 속도를 크게 높일 수 있는 기회를 얻습니다.

PR_calculate가 설정되지 않으면 이미 승인된 범용 참조 문제가 사용됩니다.

PS PR_calculate는 클라우드에서 작업을 배포 하는 데만 사용됩니다. 비용을 계산하기 위해 모든 것이 동일한 PR로 유지됩니다.

PPS 물론 함정이 있습니다. 먼저 모든 자유 계약 선수에 대해 PR_calculate를 실행해야 합니다. PR_calculate의 철자가 틀릴 수 있습니다. 따라서 PR_calculate를 계산하는 동안 고전적인 PR 체계에 따라 돈을 가져가십시오. 등.

 
hrenfx :

옵티마이저의 비용은 항상 일정하지만 기간은 PR의 적절한(이 작업에 대한) 계산에 크게 의존하기 때문에 양심에 따라 EX5 PR_calculate의 코드에 최적화 입력을 도입할 가치가 있습니다. 옵티마이저는 자신의 알고리즘 기능을 기반으로 자신의 작업에 가장 적합한 분배 PR의 계산을 스스로 설정합니다.

불행히도 프로그래머 자신이 PR을 자신에게 고려할 때 그러한 옵션은 어떤 식 으로든 작동하지 않습니다.