테스터에서도 작동할 수 있지만 OpenCL 1.0 전문가에서는 작동하지 않습니다. Rinat가 말했듯이 "이중 부동 소수점이 없기 때문"이 아니라 정확히는 위에서 말했듯이 안전 장치가 부족하기 때문입니다. OpenCL 1.0의 스레딩 및 MT4-5의 흐름이 있는 도약의 경우.
일반적으로 OpenCL(및 CUDA)에는 많은 혼란이 있습니다. 무엇을 원하십니까? 결국, 라디오 엔지니어들은 프로그래밍의 개념을 바꾸기 시작했습니다. 그들은 또한 철의 정신을 가지고 있습니다.
문제는 소위 "플랫폼 선택" 에도 있습니다. 프로그램, 즉 MT 또는 전문가의 DLL 또는 전문가는 반드시 수동으로 플랫폼(AMD, Nvidia, Intel)을 선택해야 합니다. 컴퓨터에서 OpenCL 커널을 시작한 다음 컴퓨터에 다중 GPU가 있는 경우 수동으로 DEVICE를 선택하는 컴퓨터가 여러 개일 수 있습니다. OpenCL에는 아직 자동 플랫폼 선택이 없습니다. Rinat는 "가장 강력한 자동 선택"에 대해 이야기하지만 그것이 어떤 것인지 모르겠습니다. 표시된 예에서는 플랫폼 선택 및 장치(GPU, CPU) 선택이 없습니다.
또한 표준의 여러 GPU 또는 GPU + CPU에서 OpenCL 작업의 자동 병렬화가 아직 없습니다. AMD는 드라이버/SDK의 일부 버전에서 자동 디스패칭을 수행했지만 문제가 있었고 AMD는 현재 이 기능을 껐습니다.
요약하면: MT4-5용 OpenCL 프로그램을 개발하고 활성화하려면 몇 가지 수동 노력 이 필요하므로 자동으로 또는 "옵션으로 다시 컴파일"하여 작동하지 않습니다. 실제 작업에는 많은 플러그가 있습니다. 이것은 좋은 일이 될 것이며, 중요한 것은, 불행히도 이것은 HARDWARE ORIENTED PROGRAMMING이며, 이는 잘못된 것입니다. CUDA 또는 OpenCL용 병렬 프로그램 디버깅은 하드웨어 혁명가들이 예상한 것보다 훨씬 더 어려운 것으로 나타났습니다. Nvidia는 드라이버 문제와 디버그 결함에 대한 많은 불만으로 인해 가을 2011 CUDA 컨퍼런스를 취소했습니다. 글쎄, 그들은 최신 툴킷에 1000개의 새로운 기능 을 추가했습니다. 그리고 가장 간단한 프로그램이라도 일반 사람들에게 작동하지 않거나 플러그와 함께 제공된다면 이제 어떻게 해야 할까요? 결국 그들은 설명 도구에서 OpenCL 또는 CUDA의 내부 메커니즘 작업의 절반도 표시하지 않았습니다.
드라이버 또는 프로그램 호환성으로 인해 정지된 비디오 카드의 GPU 속도(Gigaflops)는 0입니다.
일반적으로 OpenCL(및 CUDA)에는 많은 혼란이 있습니다. 무엇을 원하십니까? 결국 라디오 엔지니어들은 프로그래밍의 개념을 바꾸기 시작했습니다. 그들은 또한 철의 정신을 가지고 있습니다.
문제는 소위 "플랫폼 선택" 에도 있습니다. 프로그램, 즉 MT 또는 전문가의 DLL 또는 전문가는 반드시 수동으로 플랫폼(AMD, Nvidia, Intel)을 선택해야 합니다. 컴퓨터에서 OpenCL 커널을 시작한 다음 컴퓨터에 다중 GPU가 있는 경우 수동으로 DEVICE를 선택하는 컴퓨터가 여러 개일 수 있습니다. OpenCL에는 아직 자동 플랫폼 선택이 없습니다. Rinat는 "가장 강력한 자동 선택"에 대해 이야기하지만 그것이 어떤 것인지 모르겠습니다. 표시된 예에서는 플랫폼 선택 및 장치(GPU, CPU) 선택이 없습니다.
또한 표준의 여러 GPU 또는 GPU + CPU에서 OpenCL 작업의 자동 병렬화가 아직 없습니다. AMD는 드라이버/SDK의 일부 버전에서 자동 디스패칭을 수행했지만 문제가 있었고 AMD는 현재 이 기능을 껐습니다.
요약하면: MT4-5용 OpenCL 프로그램을 개발하고 활성화하려면 몇 가지 수동 노력 이 필요하므로 자동으로 또는 "옵션으로 다시 컴파일"하여 작동하지 않습니다. 실제 작업에는 많은 플러그가 있습니다. 이것은 좋은 일이 될 것이며, 중요한 것은, 불행히도 이것은 HARDWARE ORIENTED PROGRAMMING이며, 이는 잘못된 것입니다. CUDA 또는 OpenCL용 병렬 프로그램 디버깅은 하드웨어 혁명가들이 예상한 것보다 훨씬 더 어려운 것으로 나타났습니다. Nvidia는 드라이버 문제와 디버그 결함에 대한 많은 불만으로 인해 가을 2011 CUDA 컨퍼런스를 취소했습니다. 글쎄, 그들은 최신 툴킷에 1000개의 새로운 기능 을 추가했습니다. 그리고 가장 간단한 프로그램이라도 일반 사람들에게 작동하지 않거나 플러그와 함께 제공된다면 이제 어떻게 해야 할까요? 결국 그들은 설명 도구에서 OpenCL 또는 CUDA의 내부 메커니즘 작업의 절반도 표시하지 않았습니다.
드라이버 또는 프로그램 호환성으로 인해 정지된 비디오 카드의 GPU 속도(Gigaflops)는 0입니다.
"맞아, 그렇지? 하지만 동전에는 또 다른 면이 있다." ( "코카서스의 죄수", C). 메타 인용문은 마지막으로 "시대에 뒤쳐지지 않습니다." 그리고 귀하의 질문(정확한)은 그들의 문제가 아니라 철, 장작 및 OS의 개발자입니다.
그들은 MQL5에서 OMP를 기본적으로 지원합니다. 간단하고 화가 나며 dll을 작성할 필요가 없습니다.
그리고 미완성 철 프로그래밍 언어로 만들어진 이 꿀벌 떼는 ... 여하튼 지금까지는 그다지 고무적이지 않습니다. 글쎄요. 어떤 경우에는 100배의 속도 향상이 훌륭하지만 프로그래밍 문화의 관점에서 보면 이것은 한 발 물러난 것입니다.
또한 mql4가 MQL5보다 빠르게 작동할 때 사실을 만났습니다. 이것은 프로거 최적화 수학 연산에서 가장 자주 나타납니다.
그러나 이것이 주요 문제가 아니라고 생각합니다. OpenCL MQ로 가는 동안 우리는 주요 프로그래밍 도로와 평행하게 달리는 길에 있게 되었습니다. 아마도 당분간은 후퇴가 필요할 것입니다. 그러나 미래의 컴퓨터 기술 개발에서 우리는 복잡한 것을 보게 될 것입니다. 직렬 처리 또는 병렬 처리 여부에 관계없이 코드에 따라 달라지는 확장 가능한 시스템.
따라서 경로는 옳습니다. 오늘날에는 병렬 접근 방식을 구현 해야 하는 알고리즘이 많지 않지만 수학적 사고에는 병렬 계산을 구현하는 장비가 없었고 따라서 이러한 알고리즘을 만들 필요가 없었기 때문일 가능성이 더 큽니다.
Aleksey, 한 가지 사실을 생각해 보십시오. 모든 수학적 발견은 200-300년 전에 이루어졌습니다. 지난 100년 동안 수학적 사고는 단순히 있는 것을 연마했습니다. 그리고 국회의 발견만이 병렬계산에 대한 요청을 형성했다. 향후 100년 동안 본질적으로 병렬 알고리즘이 등장할 것입니다. 그리고 그 중 하나를 발명할 수도 있습니다.
또한 mql4가 MQL5보다 빠르게 작동할 때 사실을 만났습니다. 이것은 프로거 최적화 수학 연산에서 가장 자주 나타납니다.
그러나 이것이 주요 문제가 아니라고 생각합니다. OpenCL MQ로 가는 동안 우리는 주요 프로그래밍 도로와 평행하게 달리는 길에 있게 되었습니다. 아마도 당분간은 후퇴가 필요할 것입니다. 그러나 미래의 컴퓨터 기술 개발에서 우리는 복잡한 것을 보게 될 것입니다. 직렬 처리 또는 병렬 처리 여부에 관계없이 코드에 따라 달라지는 확장 가능한 시스템.
따라서 경로는 옳습니다. 오늘날에는 병렬 접근 방식을 구현 해야 하는 알고리즘이 많지 않지만 수학적 사고에는 병렬 계산을 구현하는 장비가 없었고 따라서 이러한 알고리즘을 만들 필요가 없었기 때문일 가능성이 더 큽니다.
Aleksey, 한 가지 사실을 생각해 보십시오. 모든 수학적 발견은 200-300년 전에 이루어졌습니다. 지난 100년 동안 수학적 사고는 단순히 있는 것을 연마했습니다. 그리고 국회의 발견만이 병렬계산에 대한 요청을 형성했다. 향후 100년 동안 본질적으로 병렬 알고리즘이 등장할 것입니다. 그리고 그 중 하나를 발명할 수도 있습니다.
잘한 MQ, 그들은 GPU에서 계산 지원을 도입하는 것과 같은 치질을 다루는 것을 두려워하지 않았습니다. 치질은 우선 근본적으로 새로운 기술(모든 것)의 도입이 첫 번째 커플에서 플랫폼 전체의 신뢰성과 내결함성을 감소시킨다는 사실과 관련이 있습니다. 그러나 그들은 미래가 병렬 컴퓨팅 에 속한다는 것을 잘 알고 있으며 조만간 이 방향으로 무언가를 해야 할 것입니다(첫 번째 단계는 이미 수행되었습니다-클라우드).
나는 Mischek 이 한 달 전에 이것에 대해 소리 쳤다고 생각합니다.
과중한 테스트나 매우 집중적인 병렬 계산을 위한 OpenCL의 범위를 봅니다.
여기까지는 그럴 필요가 없었지만(나는 인듀서의 init()에 모든 무거운 계산을 가지고 있다), 나는 메모했다.
Alexey, 같은 문제가 있습니다. init에 무언가를 드래그하려고 노력하고 그 후에야 실시간으로 :)
두뇌는 절차적 언어로 바뀌었습니다. OOP - 바람직하지만 - 네이티브가 아닙니다.
mql5.com을 보지 않는 광적인 쿼드를 위해 : OpenCL: MQL5의 내부 구현 테스트
고마워, 나는 그것을 직접 보지 못했다. 그러나 모든 것이 그렇게 간단하지는 않습니다.
또한 Rinat는 사람들을 혼란스럽게 합니다. OpenCL 1.0은 이중 부동 소수점과 함께 잘 작동할 수 있으며 모든 제조업체에서 지원하는 "공개 옵션으로" 제공되지만 모든 기존 카드에는 적용되지 않습니다.
http://www.khronos.org/registry/cl/sdk/1.0/docs/man/xhtml/
"선택적 배정밀도 및 반부동 소수점
OpenCL 1.0은 선택적 확장으로서 배정밀도 및 반 부동 소수점에 대한 지원을 추가합니다. 배정 밀도 데이터 형식은 IEEE-754 배정밀도 저장 형식을 확인해야 합니다.
double 을 사용하려는 응용 프로그램은 커널 코드에서 배정밀도 데이터 유형을 선언하기 전에 #pragma OPENCL EXTENSION cl_khr_fp64 : enable 지시문을 포함해야 합니다. 이렇게 하면 내장 벡터 및 스칼라 데이터 유형 목록이 다음을 포함하도록 확장됩니다......"
테스터에서도 작동할 수 있지만 OpenCL 1.0 전문가에서는 작동하지 않습니다. Rinat가 말했듯이 "이중 부동 소수점이 없기 때문"이 아니라 정확히는 위에서 말했듯이 안전 장치가 부족하기 때문입니다. OpenCL 1.0의 스레딩 및 MT4-5의 흐름이 있는 도약의 경우.
일반적으로 OpenCL(및 CUDA)에는 많은 혼란이 있습니다. 무엇을 원하십니까? 결국, 라디오 엔지니어들은 프로그래밍의 개념을 바꾸기 시작했습니다. 그들은 또한 철의 정신을 가지고 있습니다.
문제는 소위 "플랫폼 선택" 에도 있습니다. 프로그램, 즉 MT 또는 전문가의 DLL 또는 전문가는 반드시 수동으로 플랫폼(AMD, Nvidia, Intel)을 선택해야 합니다. 컴퓨터에서 OpenCL 커널을 시작한 다음 컴퓨터에 다중 GPU가 있는 경우 수동으로 DEVICE를 선택하는 컴퓨터가 여러 개일 수 있습니다. OpenCL에는 아직 자동 플랫폼 선택이 없습니다. Rinat는 "가장 강력한 자동 선택"에 대해 이야기하지만 그것이 어떤 것인지 모르겠습니다. 표시된 예에서는 플랫폼 선택 및 장치(GPU, CPU) 선택이 없습니다.
또한 표준의 여러 GPU 또는 GPU + CPU에서 OpenCL 작업의 자동 병렬화가 아직 없습니다. AMD는 드라이버/SDK의 일부 버전에서 자동 디스패칭을 수행했지만 문제가 있었고 AMD는 현재 이 기능을 껐습니다.
요약하면: MT4-5용 OpenCL 프로그램을 개발하고 활성화하려면 몇 가지 수동 노력 이 필요하므로 자동으로 또는 "옵션으로 다시 컴파일"하여 작동하지 않습니다. 실제 작업에는 많은 플러그가 있습니다. 이것은 좋은 일이 될 것이며, 중요한 것은, 불행히도 이것은 HARDWARE ORIENTED PROGRAMMING이며, 이는 잘못된 것입니다. CUDA 또는 OpenCL용 병렬 프로그램 디버깅은 하드웨어 혁명가들이 예상한 것보다 훨씬 더 어려운 것으로 나타났습니다. Nvidia는 드라이버 문제와 디버그 결함에 대한 많은 불만으로 인해 가을 2011 CUDA 컨퍼런스를 취소했습니다. 글쎄, 그들은 최신 툴킷에 1000개의 새로운 기능 을 추가했습니다. 그리고 가장 간단한 프로그램이라도 일반 사람들에게 작동하지 않거나 플러그와 함께 제공된다면 이제 어떻게 해야 할까요? 결국 그들은 설명 도구에서 OpenCL 또는 CUDA의 내부 메커니즘 작업의 절반도 표시하지 않았습니다.
드라이버 또는 프로그램 호환성으로 인해 정지된 비디오 카드의 GPU 속도(Gigaflops)는 0입니다.
고마워, 나는 그것을 직접 보지 못했다. 그러나 모든 것이 그렇게 간단하지는 않습니다.
....예, 일반적으로 요점이 아닙니다. 5에서 절차적 스타일로 작성할 수도 있습니다.
joo: 그리고, 이 사실에 낙심했어, akhtung! - dll을 호출하는 MQL4 스크립트는 동일한 dll을 사용하는 MQL5 스크립트보다 빠르게 작동합니다 ...
그러나 이것은 불안합니다.
그들은 MQL5에서 OMP를 기본적으로 지원합니다. 인코더에 대해 간단하고 화를 낼 것이며 dll을 작성할 필요가 없습니다.
그리고 미완성 철 프로그래밍 언어로 만들어진 이 꿀벌 떼는 ... 여하튼 지금까지는 그다지 고무적이지 않습니다. 글쎄요. 어떤 경우에는 100배의 속도 향상이 훌륭하지만 프로그래밍 문화의 관점에서 보면 이것은 한 발 물러난 것입니다.
일반적으로 OpenCL(및 CUDA)에는 많은 혼란이 있습니다. 무엇을 원하십니까? 결국 라디오 엔지니어들은 프로그래밍의 개념을 바꾸기 시작했습니다. 그들은 또한 철의 정신을 가지고 있습니다.
문제는 소위 "플랫폼 선택" 에도 있습니다. 프로그램, 즉 MT 또는 전문가의 DLL 또는 전문가는 반드시 수동으로 플랫폼(AMD, Nvidia, Intel)을 선택해야 합니다. 컴퓨터에서 OpenCL 커널을 시작한 다음 컴퓨터에 다중 GPU가 있는 경우 수동으로 DEVICE를 선택하는 컴퓨터가 여러 개일 수 있습니다. OpenCL에는 아직 자동 플랫폼 선택이 없습니다. Rinat는 "가장 강력한 자동 선택"에 대해 이야기하지만 그것이 어떤 것인지 모르겠습니다. 표시된 예에서는 플랫폼 선택 및 장치(GPU, CPU) 선택이 없습니다.
또한 표준의 여러 GPU 또는 GPU + CPU에서 OpenCL 작업의 자동 병렬화가 아직 없습니다. AMD는 드라이버/SDK의 일부 버전에서 자동 디스패칭을 수행했지만 문제가 있었고 AMD는 현재 이 기능을 껐습니다.
요약하면: MT4-5용 OpenCL 프로그램을 개발하고 활성화하려면 몇 가지 수동 노력 이 필요하므로 자동으로 또는 "옵션으로 다시 컴파일"하여 작동하지 않습니다. 실제 작업에는 많은 플러그가 있습니다. 이것은 좋은 일이 될 것이며, 중요한 것은, 불행히도 이것은 HARDWARE ORIENTED PROGRAMMING이며, 이는 잘못된 것입니다. CUDA 또는 OpenCL용 병렬 프로그램 디버깅은 하드웨어 혁명가들이 예상한 것보다 훨씬 더 어려운 것으로 나타났습니다. Nvidia는 드라이버 문제와 디버그 결함에 대한 많은 불만으로 인해 가을 2011 CUDA 컨퍼런스를 취소했습니다. 글쎄, 그들은 최신 툴킷에 1000개의 새로운 기능 을 추가했습니다. 그리고 가장 간단한 프로그램이라도 일반 사람들에게 작동하지 않거나 플러그와 함께 제공된다면 이제 어떻게 해야 할까요? 결국 그들은 설명 도구에서 OpenCL 또는 CUDA의 내부 메커니즘 작업의 절반도 표시하지 않았습니다.
드라이버 또는 프로그램 호환성으로 인해 정지된 비디오 카드의 GPU 속도(Gigaflops)는 0입니다.
예, 일반적으로 요점이 아닙니다. 5에 절차적 스타일로 작성할 수 있습니다.
그러나 이것은 불안합니다.
그들은 MQL5에서 OMP를 기본적으로 지원합니다. 간단하고 화가 나며 dll을 작성할 필요가 없습니다.
그리고 미완성 철 프로그래밍 언어로 만들어진 이 꿀벌 떼는 ... 여하튼 지금까지는 그다지 고무적이지 않습니다. 글쎄요. 어떤 경우에는 100배의 속도 향상이 훌륭하지만 프로그래밍 문화의 관점에서 보면 이것은 한 발 물러난 것입니다.
또한 mql4가 MQL5보다 빠르게 작동할 때 사실을 만났습니다. 이것은 프로거 최적화 수학 연산에서 가장 자주 나타납니다.
그러나 이것이 주요 문제가 아니라고 생각합니다. OpenCL MQ로 가는 동안 우리는 주요 프로그래밍 도로와 평행하게 달리는 길에 있게 되었습니다. 아마도 당분간은 후퇴가 필요할 것입니다. 그러나 미래의 컴퓨터 기술 개발에서 우리는 복잡한 것을 보게 될 것입니다. 직렬 처리 또는 병렬 처리 여부에 관계없이 코드에 따라 달라지는 확장 가능한 시스템.
따라서 경로는 옳습니다. 오늘날에는 병렬 접근 방식을 구현 해야 하는 알고리즘이 많지 않지만 수학적 사고에는 병렬 계산을 구현하는 장비가 없었고 따라서 이러한 알고리즘을 만들 필요가 없었기 때문일 가능성이 더 큽니다.
Aleksey, 한 가지 사실을 생각해 보십시오. 모든 수학적 발견은 200-300년 전에 이루어졌습니다. 지난 100년 동안 수학적 사고는 단순히 있는 것을 연마했습니다. 그리고 국회의 발견만이 병렬계산에 대한 요청을 형성했다. 향후 100년 동안 본질적으로 병렬 알고리즘이 등장할 것입니다. 그리고 그 중 하나를 발명할 수도 있습니다.
또한 mql4가 MQL5보다 빠르게 작동할 때 사실을 만났습니다. 이것은 프로거 최적화 수학 연산에서 가장 자주 나타납니다.
그러나 이것이 주요 문제가 아니라고 생각합니다. OpenCL MQ로 가는 동안 우리는 주요 프로그래밍 도로와 평행하게 달리는 길에 있게 되었습니다. 아마도 당분간은 후퇴가 필요할 것입니다. 그러나 미래의 컴퓨터 기술 개발에서 우리는 복잡한 것을 보게 될 것입니다. 직렬 처리 또는 병렬 처리 여부에 관계없이 코드에 따라 달라지는 확장 가능한 시스템.
따라서 경로는 옳습니다. 오늘날에는 병렬 접근 방식을 구현 해야 하는 알고리즘이 많지 않지만 수학적 사고에는 병렬 계산을 구현하는 장비가 없었고 따라서 이러한 알고리즘을 만들 필요가 없었기 때문일 가능성이 더 큽니다.
Aleksey, 한 가지 사실을 생각해 보십시오. 모든 수학적 발견은 200-300년 전에 이루어졌습니다. 지난 100년 동안 수학적 사고는 단순히 있는 것을 연마했습니다. 그리고 국회의 발견만이 병렬계산에 대한 요청을 형성했다. 향후 100년 동안 본질적으로 병렬 알고리즘이 등장할 것입니다. 그리고 그 중 하나를 발명할 수도 있습니다.
아니, 당신은 완전히 희망이 없습니다. :)
안녕하세요.
잘한 MQ, 그들은 GPU에서 계산 지원을 도입하는 것과 같은 치질을 다루는 것을 두려워하지 않았습니다. 치질은 우선 근본적으로 새로운 기술(모든 것)의 도입이 첫 번째 커플에서 플랫폼 전체의 신뢰성과 내결함성을 감소시킨다는 사실과 관련이 있습니다. 그러나 그들은 미래가 병렬 컴퓨팅 에 속한다는 것을 잘 알고 있으며 조만간 이 방향으로 무언가를 해야 할 것입니다(첫 번째 단계는 이미 수행되었습니다-클라우드).
PS 안녕하세요 니콜라이 . 사라진 이유는? - 개인 파업.
이것은 사실이 아닙니다. 왜냐하면 이것은 사실이 아닙니다. 수학의 질적 발전은 중단된 적이 없습니다.
네, 그리고 병렬 계산은 NN 뿐만 아니라 더 많은 일상적인 작업도 필요합니다(예: 비디오 인코딩 또는 렌더링).
하지만 MQ의 일반적인 움직임은 물론 고무적일 수밖에 없다.