http://www.ixbt.com/video3/rad2.shtml. - OpenCL에서 프로그램을 작성할 때 "창의성"에 참여하기 보다는 대용량 데이터 배열에 최적화된 라이브러리를 사용하는 것이 가장 좋습니다(이 사실을 배제하지 않습니다) . 하이브리드 컴퓨팅 시스템을 사용할 수 있으며 작은 볼륨은OpenCL을 사용하여 처리되고 큰 볼륨은 최적화된 라이브러리에서 처리됩니다. 예! 라이브러리를 특정 프로그래밍 언어로 변환하고 이 라이브러리를 포함하기 위한 조건을 만들어야 할 수도 있습니다. 이것이 실현될 수 있다면 인상적인 결과와 그에 따른 작업의 다중 가속이 얻어질 것입니다. 이 점 주의하세요.....
그리고 일반적으로 훌륭합니다. 이해합니다. HD 4870을 저렴하게 구입하고 그 성능을 확인하게 되어 기뻤습니다.
작은 권장 사항: GPU의 실행 시간이 1초와 비슷하도록 매개변수를 선택하십시오. 그러면 시간 비율이 더 정확할 것입니다. GteTickCount() 함수의 평균 오류는 수십 밀리초 이상입니다. 따라서 GPU의 시간은 120ms와 170ms를 모두 쉽게 얻을 수 있습니다. 그리고 가속도는 이것에 달려 있습니다.
여기에서 사용 가능한 모든 장치를 통해 실행되도록 이 스크립트를 약간 수정했습니다(아래에서 위로: 1) Intel 플랫폼의 CPU, 2) AMD 플랫폼의 HD 4870 비디오 카드, 3) AMD 플랫폼의 CPU) :
2012.05 . 3115 : 48 : 35 OpenCL CPU: GenuineIntel Intel(R) Pentium(R) CPU G840 @ 2.80 GHz with OpenCL 1.2 ( 2 units, 2793 MHz, 8040 Mb, version2.0 (sse2))
2012.05 . 3115 : 48 : 35 OpenCL GPU: Advanced Micro Devices, Inc. ATI RV770 with OpenCL 1.0 ( 10 units, 780 MHz, 512 Mb, version CAL 1.4 . 1720 )
2012.05 . 3115 : 48 : 35 OpenCL CPU: Intel(R) Corporation Intel(R) Pentium(R) CPU G840 @ 2.80 GHz with OpenCL 1.1 ( 2 units, 2800 MHz, 8040 Mb, version1.1 )
Renat : 정보: GetTickCount에 16ms 미만의 오류가 있습니다. Windows 95를 사용하고 있지 않습니다.
오류는 실제로 훨씬 적습니다. 예, 그것에 가깝지만 평균에서 32, 48 및 그 이상을 그룹화하는 이상치가 있습니다. 그것들은 드물고 나는 논쟁하지 않습니다. 그것들은 무시될 수 있습니다.
그러나 사람이 스크립트를 실행할 때 반드시 컴퓨터에서 아무 것도 하지 않는 것은 아닙니다. 또한 시스템은 작업을 수행할 수 있으므로 실행 속도가 느려질 수 있습니다.
공식적으로 표준 편차 는 6-7 범위에서 정말 작으며 실행 시간 자체에 약하게 의존합니다. 그러나 실제 분산을 잘 반영하지 않습니다. 다음은 동일한 계산을 수행할 때 기록된 시간의 히스토그램입니다.
인접한 열 사이의 거리는 16ms입니다. 작은 막대는 가능성이 높으며 이미 32ms 차이가 납니다. 중간 막대("실제 실행 시간")가 140밀리초이면 왼쪽 막대는 124ms이고 오른쪽 막대는 156ms입니다.
이것은 GPU에서 작은 실행 시간으로 나눌 때 실제 확산이 다소 클 수 있음을 의미합니다.
20초/124ms ~ 161
20초/156ms ~ 128.
이 경우 실행 시간의 "실제 비율"은 대략 가장 큰 열에 해당합니다.
20초/140ms ~ 143.
GPU에서 더 많은 실행 시간이 걸리면 이 오류의 영향이 훨씬 줄어듭니다. 글쎄, 적어도 500ms로 하자.
시뮬레이션용 스크립트:
#define BIG 10000000#define SMALL 1000voidOnStart ( )
{
Print ( "Script started..." );
double k;
int times[ SMALL ];
MathSrand ( TimeCurrent ( ) );
for ( int ii = 0 ; ii < SMALL; ii ++ )
{
Comment ( ii );
int st = GetTickCount ( );
for ( int i = 0 ; i < BIG; i ++ ) k = sin ( i );
int timeTotal = GetTickCount ( ) - st;
times[ ii ] = timeTotal;
}
int h = FileOpen ( "gtc_times.txt" , FILE_WRITE , "\r\n" );
for ( int ii = 0 ; ii < SMALL; ii ++ )
FileWrite ( h, times[ ii ] );
FileClose ( h );
Print ( "Script unloaded" );
}
//+------------------------------------------------------------------+
http://www.ixbt.com/video3/rad2.shtml . - OpenCL에서 프로그램을 작성할 때 "창의성"에 참여하기 보다는 대용량 데이터 배열에 최적화된 라이브러리를 사용하는 것이 가장 좋습니다(이 사실을 배제하지 않습니다) . 하이브리드 컴퓨팅 시스템을 사용할 수 있으며 작은 볼륨은 OpenCL을 사용하여 처리되고 큰 볼륨은 최적화된 라이브러리에서 처리됩니다. 예! 라이브러리를 특정 프로그래밍 언어로 변환하고 이 라이브러리를 포함하기 위한 조건을 만들어야 할 수도 있습니다. 이것이 실현될 수 있다면 인상적인 결과와 그에 따른 작업의 다중 가속이 얻어질 것입니다. 이 점 주의하세요.....
추신 아마도 이것은 포럼의 새로운 스레드일 것입니다.
개발자에게는 비기술적입니다. 컴파일러를 특정 제품에 맞게 조정하는 것은 비기술적입니다.
그리고 지금까지 그렇게 거대한 크기의 곱셈 행렬을 필요로 하는 거래 작업을 보지 못했습니다.
MetaTrader 5 업데이트 공지
며칠 내로 MetaTrader 5 플랫폼에 대한 업데이트가 게시될 예정이며, 업데이트가 게시된 후 최종 변경 사항 목록과 빌드 번호 가 포함된 추가 뉴스가 발표될 것입니다. 다음 변경이 예정되어 있습니다.
MetaTrader 5 클라이언트 터미널 빌드 648
MetaTester: 테스트 에이전트에서 OpenCL 프로그램 사용에 대한 지원이 추가되었습니다.
OpenCL을 이해했다면 Cloud+OpenCL에 대한 테스트 작업을 준비합니다. 매우 흥미로운 매트. 관점.
MetaDriver 에 더 가깝습니다. ...........................
최근 업데이트된 비디오 드라이버(NVIDIA 301.42 ).
관심을 끌기 위해 이전 테스트(ParallelTester_00-01x) 중 하나를 수행했고 내 눈을 믿을 수 없었습니다.
24페이지에서 테스트를 해보니 29가 증가해서 메모리를 2채널 모드로 했더니 39가 되었습니다.
현재: ~306
불가사의. NVIDIA가 운전자를 인간적으로 부추긴 것 같습니다.fyords , 하지만 이전 이벤트를 위의 로그에 어떻게 표시했습니까?
그리고 일반적으로 훌륭합니다. 이해합니다. HD 4870을 저렴하게 구입하고 그 성능을 확인하게 되어 기뻤습니다.
작은 권장 사항: GPU의 실행 시간이 1초와 비슷하도록 매개변수를 선택하십시오. 그러면 시간 비율이 더 정확할 것입니다. GteTickCount() 함수의 평균 오류는 수십 밀리초 이상입니다. 따라서 GPU의 시간은 120ms와 170ms를 모두 쉽게 얻을 수 있습니다. 그리고 가속도는 이것에 달려 있습니다.
여기에서 사용 가능한 모든 장치를 통해 실행되도록 이 스크립트를 약간 수정했습니다(아래에서 위로: 1) Intel 플랫폼의 CPU, 2) AMD 플랫폼의 HD 4870 비디오 카드, 3) AMD 플랫폼의 CPU) :
스크립트 결과 - 아래에서 위로!
10배 더 작은 마지막 매개변수를 사용하면 내 카드가 당신만큼 빠르지 않습니다. 아마도 제대로 가속할 시간이 없을 것입니다 :)fyords , 하지만 이전 이벤트를 위의 로그에 어떻게 표시했습니까?
보고서에서 "보기"를 마우스 오른쪽 버튼으로 클릭하고 새 창에서 "요청" 버튼과 로그가 시간에 올바르게 빌드되고 읽기가 더 편리합니다(저를 위해).
그리고 스크립트에 대해 감사합니다. 내일 시도하겠습니다. 특히 Count pass = 12800인 경우 완료를 위해 매우 오래 기다려야 합니다.
지금은 Count pass = 12800 인 이전 스크립트가 있습니다.
그 증가폭은 더욱 커졌다.오류는 실제로 훨씬 적습니다. 예, 그것에 가깝지만 평균에서 32, 48 및 그 이상을 그룹화하는 이상치가 있습니다. 그것들은 드물고 나는 논쟁하지 않습니다. 그것들은 무시될 수 있습니다.
그러나 사람이 스크립트를 실행할 때 반드시 컴퓨터에서 아무 것도 하지 않는 것은 아닙니다. 또한 시스템은 작업을 수행할 수 있으므로 실행 속도가 느려질 수 있습니다.
공식적으로 표준 편차 는 6-7 범위에서 정말 작으며 실행 시간 자체에 약하게 의존합니다. 그러나 실제 분산을 잘 반영하지 않습니다. 다음은 동일한 계산을 수행할 때 기록된 시간의 히스토그램입니다.
인접한 열 사이의 거리는 16ms입니다. 작은 막대는 가능성이 높으며 이미 32ms 차이가 납니다. 중간 막대("실제 실행 시간")가 140밀리초이면 왼쪽 막대는 124ms이고 오른쪽 막대는 156ms입니다.
이것은 GPU에서 작은 실행 시간으로 나눌 때 실제 확산이 다소 클 수 있음을 의미합니다.
20초/124ms ~ 161
20초/156ms ~ 128.
이 경우 실행 시간의 "실제 비율"은 대략 가장 큰 열에 해당합니다.
20초/140ms ~ 143.
GPU에서 더 많은 실행 시간이 걸리면 이 오류의 영향이 훨씬 줄어듭니다. 글쎄, 적어도 500ms로 하자.
시뮬레이션용 스크립트: