유전자 알고리즘이 활성화 된 MT5의 최적화 모드는 매우 느립니다. MT4에 대한 Expert Advisor를 테스트하고 최적화했습니다. 최적화 시간은 듀얼 코어에서 5분을 넘지 않습니다. MT5에 대해 동일한 Expert Advisor를 다시 작성했습니다. 최적화를 위해 설정합니다. 최적화 시간은 1시간 이상, 정확히는 거의 2시간입니다. 차이가 있습니까?
EA 버전은 CUDA에서 작동합니다. MT4에서. 지금까지는 테스트 모드에서만. 지금까지 nVidia에서 약속한 계산 가속을 얻는 것은 불가능했습니다.
여기에 두 가지 문제가 있습니다.
1. 프로그램 재작성 속도를 과장하거나 일반적으로 문서를 잘못 준비하거나 프로그래밍의 일부 필수 측면을 근본적으로 변경하는 nVidia 자체.
2. GPU에서 알고리즘을 병렬화하는 데 예상보다 훨씬 많은 시간이 걸립니다. Tse 언어에 대한 20년 이상의 경험을 바탕으로 DLL에서 CUDA-DLL로 프로그램을 포팅하기 시작했을 때 nVidia 약속은 3으로 나누어야 하고 그에 의해 주어진 알고리즘 전송 시간은 3으로 곱해야 한다고 믿었습니다. .
그러나 여기서 일반적인 규칙은 다음과 같습니다. 모든 NVIDIA 약속은 TEN으로 나누어야 하고 C에서 CUDA로 프로그램을 이식하는 예상 시간은 10을 곱해야 합니다.
참고: GPU에서 가속기의 원리를 이해한다면 3주 안에 알고리즘을 C에서 CUDA로 전송할 수 있습니다. 빌드를 확인하기 위해 직접 수행할 수도 있습니다. 즉, 프로그램은 비디오 카드에 있는 수백 또는 수천 개의 소형 프로세서 중 하나만 실행됩니다. 이것은 중앙 프로세스보다 약 70배 느리게 작동합니다. 예, 천천히, 하지만 작동합니다.
그러면 훨씬 더 많은 노력으로 프로그램 병렬화를 시작할 수 있습니다. 중앙 프로세스보다 이미 4-5배 느리게 또는 2-3배만 빠르게 작동합니다.
그러나 BUTS에서 실행되도록 ALGORITHM을 전역적으로 리메이크하려면 BUGS를 반복합니다. 전 세계의 모든 단위에서 가르치는 것처럼 일관되지 않습니다. 이것은 쉬운 일이 아닙니다.
명확히 하자면, 멀티스레딩 원리에 따라 기존의 순차 알고리즘을 병렬화하는 것은 어렵지만 이례적인 것은 아닙니다. 이것은 한 가지입니다. 같은 방식으로 GPU 속도가 5~10배 빨라집니다. 그러나 순차 알고리즘을 버스트 알고리즘으로 변환하면(내 사전에는 더 나은 단어가 없음) 수백 수천 개의 GPU 프로세서를 로드하고 nVidia에서 약속한 100배 속도 향상을 얻을 수 있습니다. 이는 문제가 될 수 있습니다.
그러나 그것은 또한 해결 가능합니다. 시간 문제일 뿐입니다.
하지만 거기엔 크림반도, 벤데라의 사람들 등등....
3. MetaTrader-4 측에서는 CUDA용 DLL 프로그램을작성할 때 문제가 없습니다.
문제는 nVidia 소프트웨어 개발자(2500명)가 MetaTrader-4-5에 채택된 멀티스레딩 모델에 대한 근본적인 불일치입니다. 또한 Nvidia는 CUDA 3.2에서 버전 4.0 이상으로 전환할 때 이 옵션을 근본적으로 변경했습니다. 더욱이, (메타 트레이더-4 및 수백 개의 다른 다중 스레드 프로그램에서와 같이) 왜 이런 일이 있었는지 묻기 시작했지만 그렇게 된 경우 응답 으로 "당신은 근본적으로 이해하지 못했습니다. 우리 KanzEption" .
어디선가 이미 들은 이야기 .... 그리고 최근 .....
4. C에서 범용 OpenCL로 직접 새 알고리즘을 전송하는 것보다 C에서 CUDA로 새로운 알고리즘을 전송하는 것이 훨씬 쉽기 때문에 이 방법을 권장합니다. 또한 말 그대로 오늘 nVidia는 CUDA-6을 공식적으로 도입해야 합니다. 이 CUDA-6에서는 이론적으로 새로운 Maxwell 시리즈 GPU 및 일부 OS에서 메모리 통합 및 제거로 인해 프로그래밍 양을 크게 줄일 수 있습니다. CPU와 GPU 간의 전송 작업.
그러나 Nvidia는 이것에 관심이 있습니다. 그녀는 이 포럼과 다른 포럼에서 내 불만 사항을 읽고 아마도 그녀의 예술적 위원회를 모았을 것입니다. 그들은 모든 측면에서 그것을 문지르고 상인도 사람이고 거래 터미널도 프로그램이라고 결정했습니다. 최신 버전의 CUDA에 도입된 특수 컴파일러 스위치는 고도로 다중 스레드된 CUDA 프로그램을 생성하기 위한 것입니다.
범용 계산에 힘이 필요한 사람들은 이제 범용 다중 프로세서 시스템에 큰 부담을 주지 않고 쉽게 얻을 수 있습니다. Intel 프로세서의 코어 수는 상당히 빠르게 증가하고 있습니다.
예를 들어, 우리 서버에는 40개의 코어가 있고 20개의 코어와 DDR4 메모리가 있는 작동하는 컴퓨터도 있습니다. 3Ghz에서 코어가 40개인 제온의 서버는 한 줄의 코드를 다시 작성할 필요 없이 코어가 56개 이상인 저주파 Xeon Phi를 고유하게 처리합니다.
당신은 약간 잘못되었습니다 (2 번. 둘 다.). 원칙적으로, 특히 GPU 프로그래밍을 시작하기 전에도 그렇게 생각했습니다.
(하나). 호스트 CPU의 "보편적 계산의 힘"은 가장 간단한 알고리즘에 대해서만 쉽게 얻을 수 있습니다. 이것은 대부분의 OpenMP 및 GPU 프로그래머를 위한 플러그입니다. CUDA가 포함된 비디오 카드는 수억 개를 판매했으며 이에 대한 프로그램은 약 300개에 불과했습니다. 금융의 경우 약 7-8개(쓸모 없는 라이브러리 컬렉션 제외)에 불과합니다.
(MT4 거래 터미널을 위한 세계 최초의 상업적으로 이용 가능한 CUDA 가속 Expert Advisor는 *아직* 존재하지 않습니다.)
이 목록은 몇 년 동안 변경되지 않았습니다.
왜요? 예, 호스트 CPU에서 쉽게 구성되는 복잡한 적응 알고리즘은 프로그래밍하기에 충분하지 않기 때문에 여전히 접혀야 합니다. 그리고 이것은 다음과 같은 이유로 그렇게 간단한 문제가 아닙니다.
ㅏ). CUDA-OpenCL GPU 모델의 기능 및 제한 사항(크기가 다른 커널은 순차적으로 실행되어야 함).
비). GPU와 호스트 프로세서 사이의 PCI 버스를 통한 데이터 전송은 전체 속도 향상을 죽입니다. 그리고 복잡한 적응 알고리즘에서는 그것들 없이는 할 수 없습니다.
(2). "한 줄의 코드를 다시 작성할 필요 없이" - 이것은 단순한 알고리즘에만 해당됩니다. GPU의 실제 대안인 OpenMP가 불가사의하게 작동한다는 사실, 즉 때로는 작동하고 때로는 쓰레기를 제공한다는 사실로 인해 상황이 악화됩니다. 한 곳에 프라그마 라인을 추가하는 것만으로 알고리즘이 바로 이렇게 병렬화되는 것은 환상이다. 이것은 사실과 거리가 멀다. 복잡한 알고리즘에서는 그래프를 작성하지 않고는 할 수 없는 데이터와 병렬 스트림 사이에 이러한 예기치 않은 관계가 발생합니다.
GPU는 완전히 다른 문제입니다. 처음에는 더 많은 작업이 있지만 프로그램은 동기화 측면에서 항상 올바르게 작동합니다. 게다가 CUDA용으로 재작성된 프로그램(커널 작성 없이도)은 정말 한 줄의 pragma를 사용하여 OpenMP로 변환되며 실제로 작동합니다. 그 후에야 OpenMP로 전송하는 것이 의미가 없습니다. CUDA-OpenCL용 커널을 추가하는 것이 훨씬 더 유망하고 안정적입니다. 놀랍게도 CUDA GPU 커널은 짧고 이해하기 쉬우며 안정적입니다.
글쎄, 절대 속도와 안정성 측면에서 호스트 CPU는 GPU에 대해 기회가 없습니다.
=금융 시장과 특히 외환은 전 세계적으로 진행되는 거대한 프로세스의 압축된 버전입니다.
= 따라서 가격 예측을 위한 aglorhythm은 간단할 수 없습니다. 따라서 현재로서는 적응적이고 비유적으로 말하면 통계적이어야 합니다.
= 따라서 좋은 알고리즘에서 시뮬레이션 및 적응형 피드백 없이는 어디에도 없습니다.
= 따라서 주문을 위해 호스트 CPU가 여전히 적합하다면(즉, 속도가 여전히 충분함) 테스트 및 최적화를 위해 GPU 없이는 작업하는 것이 거의 불가능합니다.
당신은 내가 두 번 틀렸다고 말했고, 그런 다음 증거를 가장해 완전히 관련 없는 것을 내놓았습니다.
나는 다음에 대해 정확합니다(즉시 언급됨):
범용(x86 CPU 기반) 계산/알고리즘에서 CUDA/OpenCL로 전환하는 것은 의미가 없습니다. x86 아키텍처는 개발 비용 절감, 재교육 비용, 재작성 비용(단순히 재앙임), 최종 성능은 더 높고 복잡성은 더 낮고 고주파 코어 수가 증가하고 주파수가 기본 메모리가 갑자기 증가하고 있습니다 - DDR4.
다중 코어 Xeon Phi에 대한 시도조차도 수반되는 복잡성(리눅스 기반 환경)으로 인해 죽고 기본 프로세서의 고주파수 코어의 순수한 증가를 잃어 버렸습니다.
OpenMP는 전혀 언급하지 않았습니다. 내 관점에서 OpenMP는 "겁쟁이를 위한 은총알"입니다. 실제 성능을 위해 싸우고 있다면 OpenMP로 말도 안되는 소리를 버리고 처음에 올바른/네이티브 멀티스레드 코드를 직접 작성하고 프로파일링하여 최대한 활용하십시오.
GPU 컴퓨팅을 위한 충분한 프로그램이 없다는 것을 스스로 증명했습니다. 대부분의 GPU 소프트웨어는 암호 크래커와 벙어리 광부를 포함하여 가장 단순한 경우입니다(게임에 대해서는 논의하지 않음).
제 생각에는 CPU와 기본 인프라가 매우 빠르게 발전하고 있으며 실제로 적용된 실제 응용 프로그램의 실제 성능에서 GPU를 추월합니다. 3~4년 전에는 GPU의 잠재력을 믿을 수 있었지만 이제는 모든 것이 명확해졌습니다.
당신은 내가 두 번 틀렸다고 말했고, 그런 다음 증거를 가장해 완전히 관련 없는 것을 내놓았습니다.
나는 다음에 대해 정확합니다(즉시 언급됨):
범용(x86 CPU 기반) 계산/알고리즘에서 CUDA/OpenCL로 전환하는 것은 의미가 없습니다. x86 아키텍처는 개발 비용 절감, 재교육 비용, 재작성 비용(단순히 재앙임), 최종 성능은 더 높고 복잡성은 더 낮고 고주파 코어 수가 증가하고 주파수가 기본 메모리가 갑자기 증가하고 있습니다 - DDR4.
다중 코어 Xeon Phi에 대한 시도조차도 수반되는 복잡성(리눅스 기반 환경)으로 인해 죽고 기본 프로세서의 고주파수 코어의 순수한 증가를 잃어 버렸습니다.
OpenMP는 전혀 언급하지 않았습니다. 내 관점에서 OpenMP는 "겁쟁이를 위한 은총알"입니다. 실제 성능을 위해 싸우고 있다면 OpenMP로 말도 안되는 소리를 버리고 처음에 올바른/네이티브 멀티스레드 코드를 직접 작성하고 프로파일링하여 최대한 활용하십시오.
GPU 컴퓨팅을 위한 충분한 프로그램이 없다는 것을 스스로 증명했습니다. 대부분의 GPU 소프트웨어는 암호 크래커와 벙어리 광부를 포함하여 가장 단순한 경우입니다(게임에 대해서는 논의하지 않음).
제 생각에는 CPU와 기본 인프라가 매우 빠르게 발전하고 있으며 실제로 적용된 실제 응용 프로그램의 실제 성능에서 GPU를 추월합니다. 3~4년 전에는 GPU의 잠재력을 믿을 수 있었지만 이제는 모든 것이 명확해졌습니다.
1. 호스트 CPU에서 코어의 성장률을 외삽할 때, 좋은 비디오 카드가 있는 오늘날과 같이 향후 몇 년 동안 코어 수가 3000코어에 도달할 가능성은 거의 없습니다 . 그리고 비디오 카드의 각 코어는 결국 약 1GHz에서 작동합니다. 따라서 호스트 프로세서는 GPU와 경쟁할 수 없습니다. 그러나 이것은 이러한 3000개의 코어를 작업으로 로드할 수 있을 뿐만 아니라 오늘날 하드웨어 GPU 아키텍처의 모든 함정을 우회할 수 있는 우수한 프로그램이 있다는 전제 하에 제공됩니다. 그리고 오늘날 평균 비디오 카드에서 GDDR5 메모리의 비디오 속도는 약 150GB/s입니다. 모든 유형의 DDR4(25GB/초) 메모리는 여전히 톱질해야 합니다.
4GHz 및 25Gb/s 메모리에서도 호스트 프로세서가 40-60 코어와 어떻게 경쟁할 수 있습니까?
2. Phi와 같은 외래종은 비디오 카드와 같이 필요한 지원과 다용도가 없습니다. 그러므로 그들은 죽었다.
3. 다중 스레드의 직접 프로그래밍의 필요성에 대해 - 예, 귀하의 의견에 동의하지만 이것은 어려운 방법입니다. 다중 스레드 버전에서 복잡한 새 적응 알고리즘을 즉시 작성하는 것은 매우 어렵습니다. 그리고 여기에서 말하자면 진화적으로 일할 필요가 있습니다. 그런 다음 실제로 많은 종류의 지연이 있음에도 불구하고 Windows가 다중 스레드를 얼마나 제대로 관리하는지 말할 수 없습니다. 따라서 OS에서도 소위 섬유 - 단순화 된 흐름을 생각해 냈습니다.
몇 년 후에 올 것입니다 - 이 스레드를 기억하십시오.
개인적으로 이 스레드는 매우 유용한 것으로 판명되었습니다. topikstarter가 계산 정확도 감소의 공포로 내 연약한 정신을 겁주기 시작했을 때도 마찬가지였습니다.
유전자 알고리즘이 활성화 된 MT5의 최적화 모드는 매우 느립니다. MT4에 대한 Expert Advisor를 테스트하고 최적화했습니다. 최적화 시간은 듀얼 코어에서 5분을 넘지 않습니다. MT5에 대해 동일한 Expert Advisor를 다시 작성했습니다. 최적화를 위해 설정합니다. 최적화 시간은 1시간 이상, 정확히는 거의 2시간입니다. 차이가 있습니까?
지금은 차이가 없습니다.
좀 더 정확히 말하자면, 이제 MetaTrader 5가 공개 가격으로 테스트할 때도 주도권을 잡고 있습니다. MetaTrader 4와 MetaTrader 5의 테스트 속도 비교
약속대로 바를 여는 테스트 모드를 단순화하고 고속 모드를 만들었습니다.
2년이 지났습니다.
EA 버전은 CUDA에서 작동합니다. MT4에서. 지금까지는 테스트 모드에서만. 지금까지 nVidia에서 약속한 계산 가속을 얻는 것은 불가능했습니다.
여기에 두 가지 문제가 있습니다.
1. 프로그램 재작성 속도를 과장하거나 일반적으로 문서를 잘못 준비하거나 프로그래밍의 일부 필수 측면을 근본적으로 변경하는 nVidia 자체.
2. GPU에서 알고리즘을 병렬화하는 데 예상보다 훨씬 많은 시간이 걸립니다. Tse 언어에 대한 20년 이상의 경험을 바탕으로 DLL에서 CUDA-DLL로 프로그램을 포팅하기 시작했을 때 nVidia 약속은 3으로 나누어야 하고 그에 의해 주어진 알고리즘 전송 시간은 3으로 곱해야 한다고 믿었습니다. .
그러나 여기서 일반적인 규칙은 다음과 같습니다. 모든 NVIDIA 약속은 TEN으로 나누어야 하고 C에서 CUDA로 프로그램을 이식하는 예상 시간은 10을 곱해야 합니다.
참고: GPU에서 가속기의 원리를 이해한다면 3주 안에 알고리즘을 C에서 CUDA로 전송할 수 있습니다. 빌드를 확인하기 위해 직접 수행할 수도 있습니다. 즉, 프로그램은 비디오 카드에 있는 수백 또는 수천 개의 소형 프로세서 중 하나만 실행됩니다. 이것은 중앙 프로세스보다 약 70배 느리게 작동합니다. 예, 천천히, 하지만 작동합니다.
그러면 훨씬 더 많은 노력으로 프로그램 병렬화를 시작할 수 있습니다. 중앙 프로세스보다 이미 4-5배 느리게 또는 2-3배만 빠르게 작동합니다.
그러나 BUTS에서 실행되도록 ALGORITHM을 전역적으로 리메이크하려면 BUGS를 반복합니다. 전 세계의 모든 단위에서 가르치는 것처럼 일관되지 않습니다. 이것은 쉬운 일이 아닙니다.
명확히 하자면, 멀티스레딩 원리에 따라 기존의 순차 알고리즘을 병렬화하는 것은 어렵지만 이례적인 것은 아닙니다. 이것은 한 가지입니다. 같은 방식으로 GPU 속도가 5~10배 빨라집니다. 그러나 순차 알고리즘을 버스트 알고리즘으로 변환하면(내 사전에는 더 나은 단어가 없음) 수백 수천 개의 GPU 프로세서를 로드하고 nVidia에서 약속한 100배 속도 향상을 얻을 수 있습니다. 이는 문제가 될 수 있습니다.
그러나 그것은 또한 해결 가능합니다. 시간 문제일 뿐입니다.
하지만 거기엔 크림반도, 벤데라의 사람들 등등....
3. MetaTrader-4 측에서는 CUDA용 DLL 프로그램을 작성할 때 문제가 없습니다.
문제는 nVidia 소프트웨어 개발자(2500명)가 MetaTrader-4-5에 채택된 멀티스레딩 모델에 대한 근본적인 불일치입니다. 또한 Nvidia는 CUDA 3.2에서 버전 4.0 이상으로 전환할 때 이 옵션을 근본적으로 변경했습니다. 더욱이, (메타 트레이더-4 및 수백 개의 다른 다중 스레드 프로그램에서와 같이) 왜 이런 일이 있었는지 묻기 시작했지만 그렇게 된 경우 응답 으로 "당신은 근본적으로 이해하지 못했습니다. 우리 KanzEption" .
어디선가 이미 들은 이야기 .... 그리고 최근 .....
4. C에서 범용 OpenCL로 직접 새 알고리즘을 전송하는 것보다 C에서 CUDA로 새로운 알고리즘을 전송하는 것이 훨씬 쉽기 때문에 이 방법을 권장합니다. 또한 말 그대로 오늘 nVidia는 CUDA-6을 공식적으로 도입해야 합니다. 이 CUDA-6에서는 이론적으로 새로운 Maxwell 시리즈 GPU 및 일부 OS에서 메모리 통합 및 제거로 인해 프로그래밍 양을 크게 줄일 수 있습니다. CPU와 GPU 간의 전송 작업.
잘?
그리고 뭐?
아무도 이것에 전혀 관심이 없습니까?
1년 동안, 단 한 건의 질문이나 게시물도 없습니다.
그러나 Nvidia는 이것에 관심이 있습니다. 그녀는 이 포럼과 다른 포럼에서 내 불만 사항을 읽고 아마도 그녀의 예술적 위원회를 모았을 것입니다. 그들은 모든 측면에서 그것을 문지르고 상인도 사람이고 거래 터미널도 프로그램이라고 결정했습니다. 최신 버전의 CUDA에 도입된 특수 컴파일러 스위치는 고도로 다중 스레드된 CUDA 프로그램을 생성하기 위한 것입니다.
http://devblogs.nvidia.com/parallelforall/gpu-pro-tip-cuda-7-streams-simplify-concurrency/
유형 문자열
nvcc --기본 스트림 스레드당 ./pthread_test.cu -o pthreads_per_thread
불행히도 Xeon Phi조차도 이륙하지 못했습니다. 그리고 기존의 프로그래밍에 가깝습니다.
범용 계산에 힘이 필요한 사람들은 이제 범용 다중 프로세서 시스템에 큰 부담을 주지 않고 쉽게 얻을 수 있습니다. Intel 프로세서의 코어 수는 상당히 빠르게 증가하고 있습니다.
예를 들어, 우리 서버에는 40개의 코어가 있고 20개의 코어와 DDR4 메모리가 있는 작동하는 컴퓨터도 있습니다. 3Ghz에서 코어가 40개인 제온의 서버는 한 줄의 코드를 다시 작성할 필요 없이 코어가 56개 이상인 저주파 Xeon Phi를 고유하게 처리합니다.
범용 계산에 힘이 필요한 사람들은 이제 범용 다중 프로세서 시스템에 큰 부담을 주지 않고 쉽게 얻을 수 있습니다. Intel 프로세서의 코어 수는 상당히 빠르게 증가하고 있습니다.
예를 들어, 우리 서버에는 40개의 코어가 있고 20개의 코어와 DDR4 메모리가 있는 작동하는 컴퓨터도 있습니다. 3Ghz에서 코어가 40개인 제온의 서버는 한 줄의 코드를 다시 작성할 필요 없이 코어가 56개 이상인 저주파 Xeon Phi를 고유하게 처리합니다.
당신은 약간 잘못되었습니다 (2 번. 둘 다.). 원칙적으로, 특히 GPU 프로그래밍을 시작하기 전에도 그렇게 생각했습니다.
(하나). 호스트 CPU의 "보편적 계산의 힘"은 가장 간단한 알고리즘에 대해서만 쉽게 얻을 수 있습니다. 이것은 대부분의 OpenMP 및 GPU 프로그래머를 위한 플러그입니다. CUDA가 포함된 비디오 카드는 수억 개를 판매했으며 이에 대한 프로그램은 약 300개에 불과했습니다. 금융의 경우 약 7-8개(쓸모 없는 라이브러리 컬렉션 제외)에 불과합니다.
nVidia 웹사이트의 전체 목록은 다음과 같습니다.
http://www.nvidia.com/object/gpu-applications.html?cFncE
(MT4 거래 터미널을 위한 세계 최초의 상업적으로 이용 가능한 CUDA 가속 Expert Advisor는 *아직* 존재하지 않습니다.)
이 목록은 몇 년 동안 변경되지 않았습니다.
왜요? 예, 호스트 CPU에서 쉽게 구성되는 복잡한 적응 알고리즘은 프로그래밍하기에 충분하지 않기 때문에 여전히 접혀야 합니다. 그리고 이것은 다음과 같은 이유로 그렇게 간단한 문제가 아닙니다.
ㅏ). CUDA-OpenCL GPU 모델의 기능 및 제한 사항(크기가 다른 커널은 순차적으로 실행되어야 함).
비). GPU와 호스트 프로세서 사이의 PCI 버스를 통한 데이터 전송은 전체 속도 향상을 죽입니다. 그리고 복잡한 적응 알고리즘에서는 그것들 없이는 할 수 없습니다.
(2). "한 줄의 코드를 다시 작성할 필요 없이" - 이것은 단순한 알고리즘에만 해당됩니다. GPU의 실제 대안인 OpenMP가 불가사의하게 작동한다는 사실, 즉 때로는 작동하고 때로는 쓰레기를 제공한다는 사실로 인해 상황이 악화됩니다. 한 곳에 프라그마 라인을 추가하는 것만으로 알고리즘이 바로 이렇게 병렬화되는 것은 환상이다. 이것은 사실과 거리가 멀다. 복잡한 알고리즘에서는 그래프를 작성하지 않고는 할 수 없는 데이터와 병렬 스트림 사이에 이러한 예기치 않은 관계가 발생합니다.
GPU는 완전히 다른 문제입니다. 처음에는 더 많은 작업이 있지만 프로그램은 동기화 측면에서 항상 올바르게 작동합니다. 게다가 CUDA용으로 재작성된 프로그램(커널 작성 없이도)은 정말 한 줄의 pragma를 사용하여 OpenMP로 변환되며 실제로 작동합니다. 그 후에야 OpenMP로 전송하는 것이 의미가 없습니다. CUDA-OpenCL용 커널을 추가하는 것이 훨씬 더 유망하고 안정적입니다. 놀랍게도 CUDA GPU 커널은 짧고 이해하기 쉬우며 안정적입니다.
글쎄, 절대 속도와 안정성 측면에서 호스트 CPU는 GPU에 대해 기회가 없습니다.
=금융 시장과 특히 외환은 전 세계적으로 진행되는 거대한 프로세스의 압축된 버전입니다.
= 따라서 가격 예측을 위한 aglorhythm은 간단할 수 없습니다. 따라서 현재로서는 적응적이고 비유적으로 말하면 통계적이어야 합니다.
= 따라서 좋은 알고리즘에서 시뮬레이션 및 적응형 피드백 없이는 어디에도 없습니다.
= 따라서 주문을 위해 호스트 CPU가 여전히 적합하다면(즉, 속도가 여전히 충분함) 테스트 및 최적화를 위해 GPU 없이는 작업하는 것이 거의 불가능합니다.
당신은 내가 두 번 틀렸다고 말했고, 그런 다음 증거를 가장해 완전히 관련 없는 것을 내놓았습니다.
나는 다음에 대해 정확합니다(즉시 언급됨):
OpenMP는 전혀 언급하지 않았습니다. 내 관점에서 OpenMP는 "겁쟁이를 위한 은총알"입니다. 실제 성능을 위해 싸우고 있다면 OpenMP로 말도 안되는 소리를 버리고 처음에 올바른/네이티브 멀티스레드 코드를 직접 작성하고 프로파일링하여 최대한 활용하십시오.
GPU 컴퓨팅을 위한 충분한 프로그램이 없다는 것을 스스로 증명했습니다. 대부분의 GPU 소프트웨어는 암호 크래커와 벙어리 광부를 포함하여 가장 단순한 경우입니다(게임에 대해서는 논의하지 않음).
제 생각에는 CPU와 기본 인프라가 매우 빠르게 발전하고 있으며 실제로 적용된 실제 응용 프로그램의 실제 성능에서 GPU를 추월합니다. 3~4년 전에는 GPU의 잠재력을 믿을 수 있었지만 이제는 모든 것이 명확해졌습니다.
당신은 내가 두 번 틀렸다고 말했고, 그런 다음 증거를 가장해 완전히 관련 없는 것을 내놓았습니다.
나는 다음에 대해 정확합니다(즉시 언급됨):
OpenMP는 전혀 언급하지 않았습니다. 내 관점에서 OpenMP는 "겁쟁이를 위한 은총알"입니다. 실제 성능을 위해 싸우고 있다면 OpenMP로 말도 안되는 소리를 버리고 처음에 올바른/네이티브 멀티스레드 코드를 직접 작성하고 프로파일링하여 최대한 활용하십시오.
GPU 컴퓨팅을 위한 충분한 프로그램이 없다는 것을 스스로 증명했습니다. 대부분의 GPU 소프트웨어는 암호 크래커와 벙어리 광부를 포함하여 가장 단순한 경우입니다(게임에 대해서는 논의하지 않음).
제 생각에는 CPU와 기본 인프라가 매우 빠르게 발전하고 있으며 실제로 적용된 실제 응용 프로그램의 실제 성능에서 GPU를 추월합니다. 3~4년 전에는 GPU의 잠재력을 믿을 수 있었지만 이제는 모든 것이 명확해졌습니다.
1. 호스트 CPU에서 코어의 성장률을 외삽할 때, 좋은 비디오 카드가 있는 오늘날과 같이 향후 몇 년 동안 코어 수가 3000코어에 도달할 가능성은 거의 없습니다 . 그리고 비디오 카드의 각 코어는 결국 약 1GHz에서 작동합니다. 따라서 호스트 프로세서는 GPU와 경쟁할 수 없습니다. 그러나 이것은 이러한 3000개의 코어를 작업으로 로드할 수 있을 뿐만 아니라 오늘날 하드웨어 GPU 아키텍처의 모든 함정을 우회할 수 있는 우수한 프로그램이 있다는 전제 하에 제공됩니다. 그리고 오늘날 평균 비디오 카드에서 GDDR5 메모리의 비디오 속도는 약 150GB/s입니다. 모든 유형의 DDR4(25GB/초) 메모리는 여전히 톱질해야 합니다.
4GHz 및 25Gb/s 메모리에서도 호스트 프로세서가 40-60 코어와 어떻게 경쟁할 수 있습니까?
2. Phi와 같은 외래종은 비디오 카드와 같이 필요한 지원과 다용도가 없습니다. 그러므로 그들은 죽었다.
3. 다중 스레드의 직접 프로그래밍의 필요성에 대해 - 예, 귀하의 의견에 동의하지만 이것은 어려운 방법입니다. 다중 스레드 버전에서 복잡한 새 적응 알고리즘을 즉시 작성하는 것은 매우 어렵습니다. 그리고 여기에서 말하자면 진화적으로 일할 필요가 있습니다. 그런 다음 실제로 많은 종류의 지연이 있음에도 불구하고 Windows가 다중 스레드를 얼마나 제대로 관리하는지 말할 수 없습니다. 따라서 OS에서도 소위 섬유 - 단순화 된 흐름을 생각해 냈습니다.
결론: GPU보다 저렴하고 유망하며 안정적인 것은 없습니다.