MetaDriver : 진심으로, 당신이 그것을 짜낼 수 있는 주스는 끔찍하게 흥미롭습니다. 특히 2기가 DDR5가 있다는 것이 좋습니다. 결과적으로 온보드 GPU 메모리는 OpenCL 계산을 위한 매우 중요한 리소스가 될 수 있습니다.
나에게 사용 가능한 정보 세트에서 나는 주요 리소스가 GPU 코어의 수라고 결론지었습니다. GPU 코어가 부족하여 작업이 새 스레드가 있는 코어의 연속 실행으로 나뉘지만 이 리소스를 절약하기가 어렵습니다. 카드를 구입할 때 코어가 많을수록 가격이 높아집니다.
두 번째로 중요한 것은 GPU 메모리가 작동하는 속도입니다(메모리에 자주 액세스하기 때문에). GPU 작업은 대부분 매우 원시적이며 결과를 출력하기 위해 메모리에 액세스하기 전에 1-2-3 작업을 사용합니다. 복잡한 논리 연산은 GPU에 대해 금기이므로 프로그래머의 생각은 이를 최소화하기 위해 노력할 것이며 논리적으로 더 빈번한 메모리 액세스로 이어질 것입니다. 여기에 옵션이 있습니다. 프로그래머가 작업을 설명하여 가능한 한 적은 메모리에 액세스하는 경우 이 리소스는 그다지 중요하지 않습니다.
그리고 세 번째 리소스는 GPU 메모리의 양이라고 부를 것입니다. 충돌 테스트 결과, 동시에 존재하는 컨텍스트의 수에 관계없이 컨텍스트에 할당된 모든 메모리가 하나의 메모리 필드에 분산되어 겹치지 않는 것으로 나타났습니다. 예를 들어 설명하겠습니다: 각각에 버퍼가 장치 메모리의 1/4에 분산되어 있는 N개의 컨텍스트가 있는 경우에는 4개의 컨텍스트를 동시에 가질 수 있습니다. 다섯 번째 컨텍스트에서는 생성하더라도 , 메모리는 이미 이전 컨텍스트에서 모두 배포되었으므로 할당되지 않습니다. 그러나 이전 항목 중 하나에서 메모리를 해제하면(즉, 버퍼(a) 삭제) 해당 위치가 표시되고 다섯 번째 컨텍스트가 제대로 작동합니다.
레나트 :
너무 이르다. GPU 결함과 OpenCL 프로그램 자체로 인해 OpenCL 프로그램이 전체 네트워크를 중단시키지 않도록 해야 합니다.
사실, OpenCL 프로그램은 프로그램이 작동하고 컴퓨터를 죽이지 않는지 확인하기 위해 로컬 에이전트에서 테스트를 실행한 후에만 네트워크에 릴리스될 수 있습니다.
병렬 컴퓨팅 의 분산 네트워크 작업. 이름 자체가 준비되지 않은 독자를 혼란스럽게 할 수 있습니다. 멀티 코어 시스템에서 분산 네트워크를 구성하는 데 문제가 있었다면 이제 제곱됩니다. 모든 코어는 별도의 작업을 수행하기 때문에 네트워크의 개별 단위로 간주될 수 있습니다. 그러나 이전에는 실행 속도가 최대 2-3배(저속 코어에 대한 제한을 도입한 경우) 차이가 났으며 어레이의 최대값이 10 ^ 7이기 때문에 대다수의 메모리 양이 역할을 하지 않았습니다. 요소(현대 기계의 경우 1페니).
그러나 GPU를 사용하면 작업이 크게 바뀝니다. 첫째, ~12개의 이중 배열만 길이가 10^7이며 이미 1GB입니다. 많은 카드의 경우 이것이 한계입니다. 그리고 CPU 계산에서 많은 수의 버퍼로 작업을 쉽게 접할 수 있습니다(물론 GPU에서 프로그래머는 호스트 메모리 사용을 규정할 수 있지만 이 솔루션은 간단히 말해 가상 RAM을 사용하는 것과 유사합니다. 나쁜 일).
둘째, 실행 속도의 차이는 GPU의 코어 수에 선형적으로 의존합니다. 그리고 꿀카드의 차이는 10~1000배입니다.
일반적으로 네트워킹 작업은 실행 가능한 프로그램의 분류로 축소됩니다. CUDA 프로파일러에 주의하십시오. 그것의 통계는 문제 분류의 기초로 간주될 수 있습니다. 작업이 대부분의 시간을 메모리 액세스에 소비하도록 배열되면 메모리 크기가 큰 시스템 클러스터가 필요하지만 대부분의 시간을 산술에 소비하는 경우 많은 수의 코어가 있는 클러스터가 필요합니다. . 클러스터는 유연하거나 포함할 수 있습니다(이는 구현 문제임).
시간 자체에 의해 적용된 통일로 인해 작업이 약간 단순화되지만. 12코어 카드는 256MB, 96512MB가 있을 수 있습니다. 평균적으로 제조업체는 큰 왜곡을 허용하지 않습니다(CPU와 달리 사용자 자신이 가장 용서하기 어려운 오래된 스톤에 요원을 붙일 수 있거나 그 반대의 경우도 마찬가지입니다. ).
내 생각에 더 정확한 접근 방식은 OpenCL용 디버거를 만들고 이를 기반으로 바이트 코드에서 장치 최적화를 보호하는 것입니다. 그렇지 않으면 프로그래머가 프로그램이 실행될 카드를 예측하고 가능한 사용 환경에 대한 프로그램의 세부 사항을 평균화해야 할 때 어셈블러에 도달하게 됩니다.
나에게 사용 가능한 정보 세트에서 나는 주요 리소스가 GPU 코어의 수라고 결론지었습니다. GPU 코어가 부족하여 작업이 새 스레드가 있는 코어의 연속 실행으로 나뉘지만 이 리소스를 절약하기가 어렵습니다. 카드를 구입할 때 코어가 많을수록 가격이 높아집니다.
두 번째로 가장 중요한 것은 GPU 메모리가 작동하는 속도입니다(메모리에 자주 액세스하기 때문에). GPU 작업은 대부분 매우 원시적이며 결과를 출력하기 위해 메모리에 액세스하기 전에 1-2-3 작업을 사용합니다. 복잡한 논리 연산 은 GPU에 대해 금기이므로 프로그래머의 생각은 이를 최소화하기 위해 노력할 것이며 논리적으로 더 빈번한 메모리 액세스로 이어질 것입니다. 여기에 옵션이 있습니다. 프로그래머가 작업을 설명하여 가능한 한 적은 메모리에 액세스하는 경우 이 리소스는 그다지 중요하지 않습니다.
그리고 세 번째 리소스는 GPU 메모리의 양이라고 부를 것입니다. 충돌 테스트 결과, 동시에 존재하는 컨텍스트의 수에 관계없이 컨텍스트에 할당된 모든 메모리가 하나의 메모리 필드에 분산되어 겹치지 않는 것으로 나타났습니다. 예를 들어 설명하겠습니다: 각각에 버퍼가 장치 메모리의 1/4에 분산되어 있는 N개의 컨텍스트가 있는 경우에는 4개의 컨텍스트를 동시에 가질 수 있습니다. 다섯 번째 컨텍스트에서는 생성하더라도 , 메모리는 이미 이전 컨텍스트에서 모두 배포되었으므로 할당되지 않습니다. 그러나 이전 항목 중 하나에서 메모리를 해제하면(즉, 버퍼(a) 삭제) 해당 위치가 표시되고 다섯 번째 컨텍스트가 제대로 작동합니다.
Nikolai, 나는 가치의 개별 계층에 대해 당신의 말에 동의합니다. 그러나 클라우드와 관련하여 .. 문제는 기억에 남습니다. 클라우드 시스템의 처음 두 리소스가 충분하지 않으면 클라이언트 프로그램이 느려집니다. 강하게 / 약하게 감속 - 열 번째 질문. 글쎄, 그들은 그녀에게 ipsyo의 상태를 조정할 것입니다. 그러나 GPU 메모리가 부족하면 단순히 떨어질 수 있습니다. 저것들. 드라이버가 버퍼 할당을 거부하는 경우 - 그렇게 나쁘지 않습니다. 문제는 원칙적 으로 메모리가 충분하지만 다른 GPU 컨텍스트(시스템 컨텍스트 포함)에는 남아 있지 않은 경우입니다. 그런 다음 운전자는 단순히 중단됩니다(실습에서 알 수 있듯이). 아마도 이것은 장작의 결함일 뿐이지만 존재하는 동안 OpenCL 프로그램을 클라우드에 넣지 않는 것이 좋습니다. 원격 에이전트는 할 수 있지만 클라우드에는 가치가 없습니다.
Небольшой рабочий пример расчета фрактала Мандельброта в OpenCL, который кардинально ускоряет расчеты по сравнению с софтверной реализацией примерно в 100 раз.
Andrey , 그리고 Intel + Radeon - 정말 나쁜가요?
나쁘지 않습니다. 단지 터무니없이 비쌉니다(프로세서 때문에). :)
ZY 그건 그렇고, 저는 nVidia 카드의 오랜 팬입니다. 전설적인 GeForce 3가 있는 시스템 장치도 어딘가에 있습니다. 그리고 컴퓨터가 게임용으로 선택되었다면 주저 없이 그래픽 칩의 "친환경" 제조업체에 충실할 것입니다.
진심으로, 당신이 그것을 짜낼 수 있는 주스는 끔찍하게 흥미롭습니다. 특히 2기가 DDR5가 있다는 것이 좋습니다. 결과적으로 온보드 GPU 메모리는 OpenCL 계산을 위한 매우 중요한 리소스가 될 수 있습니다.
나에게 사용 가능한 정보 세트에서 나는 주요 리소스가 GPU 코어의 수라고 결론지었습니다. GPU 코어가 부족하여 작업이 새 스레드가 있는 코어의 연속 실행으로 나뉘지만 이 리소스를 절약하기가 어렵습니다. 카드를 구입할 때 코어가 많을수록 가격이 높아집니다.
두 번째로 중요한 것은 GPU 메모리가 작동하는 속도입니다(메모리에 자주 액세스하기 때문에). GPU 작업은 대부분 매우 원시적이며 결과를 출력하기 위해 메모리에 액세스하기 전에 1-2-3 작업을 사용합니다. 복잡한 논리 연산은 GPU에 대해 금기이므로 프로그래머의 생각은 이를 최소화하기 위해 노력할 것이며 논리적으로 더 빈번한 메모리 액세스로 이어질 것입니다. 여기에 옵션이 있습니다. 프로그래머가 작업을 설명하여 가능한 한 적은 메모리에 액세스하는 경우 이 리소스는 그다지 중요하지 않습니다.
그리고 세 번째 리소스는 GPU 메모리의 양이라고 부를 것입니다. 충돌 테스트 결과, 동시에 존재하는 컨텍스트의 수에 관계없이 컨텍스트에 할당된 모든 메모리가 하나의 메모리 필드에 분산되어 겹치지 않는 것으로 나타났습니다. 예를 들어 설명하겠습니다: 각각에 버퍼가 장치 메모리의 1/4에 분산되어 있는 N개의 컨텍스트가 있는 경우에는 4개의 컨텍스트를 동시에 가질 수 있습니다. 다섯 번째 컨텍스트에서는 생성하더라도 , 메모리는 이미 이전 컨텍스트에서 모두 배포되었으므로 할당되지 않습니다. 그러나 이전 항목 중 하나에서 메모리를 해제하면(즉, 버퍼(a) 삭제) 해당 위치가 표시되고 다섯 번째 컨텍스트가 제대로 작동합니다.
너무 이르다. GPU 결함과 OpenCL 프로그램 자체로 인해 OpenCL 프로그램이 전체 네트워크를 중단시키지 않도록 해야 합니다.
사실, OpenCL 프로그램은 프로그램이 작동하고 컴퓨터를 죽이지 않는지 확인하기 위해 로컬 에이전트에서 테스트를 실행한 후에만 네트워크에 릴리스될 수 있습니다.
병렬 컴퓨팅 의 분산 네트워크 작업. 이름 자체가 준비되지 않은 독자를 혼란스럽게 할 수 있습니다. 멀티 코어 시스템에서 분산 네트워크를 구성하는 데 문제가 있었다면 이제 제곱됩니다. 모든 코어는 별도의 작업을 수행하기 때문에 네트워크의 개별 단위로 간주될 수 있습니다. 그러나 이전에는 실행 속도가 최대 2-3배(저속 코어에 대한 제한을 도입한 경우) 차이가 났으며 어레이의 최대값이 10 ^ 7이기 때문에 대다수의 메모리 양이 역할을 하지 않았습니다. 요소(현대 기계의 경우 1페니).
그러나 GPU를 사용하면 작업이 크게 바뀝니다. 첫째, ~12개의 이중 배열만 길이가 10^7이며 이미 1GB입니다. 많은 카드의 경우 이것이 한계입니다. 그리고 CPU 계산에서 많은 수의 버퍼로 작업을 쉽게 접할 수 있습니다(물론 GPU에서 프로그래머는 호스트 메모리 사용을 규정할 수 있지만 이 솔루션은 간단히 말해 가상 RAM을 사용하는 것과 유사합니다. 나쁜 일).
둘째, 실행 속도의 차이는 GPU의 코어 수에 선형적으로 의존합니다. 그리고 꿀카드의 차이는 10~1000배입니다.
일반적으로 네트워킹 작업은 실행 가능한 프로그램의 분류로 축소됩니다. CUDA 프로파일러에 주의하십시오. 그것의 통계는 문제 분류의 기초로 간주될 수 있습니다. 작업이 대부분의 시간을 메모리 액세스에 소비하도록 배열되면 메모리 크기가 큰 시스템 클러스터가 필요하지만 대부분의 시간을 산술에 소비하는 경우 많은 수의 코어가 있는 클러스터가 필요합니다. . 클러스터는 유연하거나 포함할 수 있습니다(이는 구현 문제임).
시간 자체에 의해 적용된 통일로 인해 작업이 약간 단순화되지만. 12코어 카드는 256MB, 96512MB가 있을 수 있습니다. 평균적으로 제조업체는 큰 왜곡을 허용하지 않습니다(CPU와 달리 사용자 자신이 가장 용서하기 어려운 오래된 스톤에 요원을 붙일 수 있거나 그 반대의 경우도 마찬가지입니다. ).
내 생각에 더 정확한 접근 방식은 OpenCL용 디버거를 만들고 이를 기반으로 바이트 코드에서 장치 최적화를 보호하는 것입니다. 그렇지 않으면 프로그래머가 프로그램이 실행될 카드를 예측하고 가능한 사용 환경에 대한 프로그램의 세부 사항을 평균화해야 할 때 어셈블러에 도달하게 됩니다.
어렵지 않은 경우 테스트를 실행하는 방법을 알려주십시오. 어디서, 무엇을 변경해야 합니까? 복사, 선택, 결과:
Win7 x64 빌드 607
이 예제는 테스터에서 "실행"할 필요가 없습니다. 스크립트를 실행하려면 "내비게이터"에서 차트로 마우스로 드래그하십시오. 결과는 " 도구 " 패널 " 전문가 " 탭에 표시됩니다.
w7 32비트 4GB(3.5GB 사용 가능)
Intel Core 2 Quad Q9505 Yorkfield(2833MHz, LGA775, L2 6144Kb, 1333MHz) 대 Radeon HD 5770
w7 32비트 4GB(3.5GB 사용 가능)
Intel Core 2 Quad Q9505 Yorkfield(2833MHz, LGA775, L2 6144Kb, 1333MHz) 대 Radeon HD 5770
시원한. 글쎄, 이제 어디를 파야하는지 알았습니다 ... :)
프로세서는 이미 2-3세대 뒤쳐져 있습니다.
및 비디오 5770 - 6770 -7770
:)
나에게 사용 가능한 정보 세트에서 나는 주요 리소스가 GPU 코어의 수라고 결론지었습니다. GPU 코어가 부족하여 작업이 새 스레드가 있는 코어의 연속 실행으로 나뉘지만 이 리소스를 절약하기가 어렵습니다. 카드를 구입할 때 코어가 많을수록 가격이 높아집니다.
두 번째로 가장 중요한 것은 GPU 메모리가 작동하는 속도입니다(메모리에 자주 액세스하기 때문에). GPU 작업은 대부분 매우 원시적이며 결과를 출력하기 위해 메모리에 액세스하기 전에 1-2-3 작업을 사용합니다. 복잡한 논리 연산 은 GPU에 대해 금기이므로 프로그래머의 생각은 이를 최소화하기 위해 노력할 것이며 논리적으로 더 빈번한 메모리 액세스로 이어질 것입니다. 여기에 옵션이 있습니다. 프로그래머가 작업을 설명하여 가능한 한 적은 메모리에 액세스하는 경우 이 리소스는 그다지 중요하지 않습니다.
그리고 세 번째 리소스는 GPU 메모리의 양이라고 부를 것입니다. 충돌 테스트 결과, 동시에 존재하는 컨텍스트의 수에 관계없이 컨텍스트에 할당된 모든 메모리가 하나의 메모리 필드에 분산되어 겹치지 않는 것으로 나타났습니다. 예를 들어 설명하겠습니다: 각각에 버퍼가 장치 메모리의 1/4에 분산되어 있는 N개의 컨텍스트가 있는 경우에는 4개의 컨텍스트를 동시에 가질 수 있습니다. 다섯 번째 컨텍스트에서는 생성하더라도 , 메모리는 이미 이전 컨텍스트에서 모두 배포되었으므로 할당되지 않습니다. 그러나 이전 항목 중 하나에서 메모리를 해제하면(즉, 버퍼(a) 삭제) 해당 위치가 표시되고 다섯 번째 컨텍스트가 제대로 작동합니다.
607 빌드로 업데이트한 후 opencltest가 갑자기 내 랩톱에서 작업을 시작했습니다 https://www.mql5.com/ru/code/825 , 이전에는(2주 전) 작동하지 않았고 "OpenCL을 찾을 수 없음"이라고 쓰는 것 같습니다.
"나는 내 등을 잡는 느낌이 든다", 나는 아직 Mandelbrot 프랙탈을 어지럽히지 않았다 ))))))))))))) , 그러나 새로운 랩톱이 본격적인 MT5 테스트