GPU Cuda는 강력한 비즈니스입니다. 16개의 Intel 스레드(4코어 프로세서)에서 2-3시간 동안 실행되는 코드가 있었습니다. 그리고 300개 이상의 CUDA 코어에서 10분 만에 같은 거리를 달리는 것이 인상적이었습니다. 그러나 Kudo 코드의 개발은 매우 어려웠습니다. 코드의 모든 계산을 수동으로 병렬 스레드로 나누고 메모리를 최적화해야 했습니다(안타깝게도 Kudo 코어에는 거의 없음). 나는 이것을 할 수 없었다 - 똑똑한 프로그래머가 도왔다. 나는 여전히 그의 코드를 두려워하고 내 원래(비병렬) 코드에서 모든 변경을 계속합니다. 나는 알고리즘이 안정적이라면 유능한 프로그래머의 도움으로 최적화되어 GPU로 전송될 수 있다는 의견을 제시했습니다. 나 같은 독학 프로그래머는 이 작업을 수행할 수 없습니다. 바이패스 알고리즘에 대한 GPU 코드로 바로 시작하면 바이패스 시간이 오래 걸립니다. 나 자신은 비록 차선책이지만 스스로 이해할 수 있는 간단한 코드로 시작합니다. 그리고 예상한 결과를 얻은 후에야 최적화를 시작합니다. 프로그래머가 아닌 나를 괴롭히는 것 :)
GPU Cuda는 강력한 비즈니스입니다. 16개의 Intel 스레드(4코어 프로세서)에서 2-3시간 동안 실행되는 코드가 있었습니다. 그리고 300개 이상의 CUDA 코어에서 10분 만에 같은 거리를 달리는 것이 인상적이었습니다. 그러나 Kudo 코드의 개발은 매우 어려웠습니다. 코드의 모든 계산을 수동으로 병렬 스레드로 나누고 메모리를 최적화해야 했습니다(안타깝게도 Kudo 코어에는 거의 없음). 나는 이것을 할 수 없었다 - 똑똑한 프로그래머가 도왔다. 나는 여전히 그의 코드를 두려워하고 내 원래(비병렬) 코드에서 모든 변경을 계속합니다. 나는 알고리즘이 안정적이라면 유능한 프로그래머의 도움으로 최적화되어 GPU로 전송될 수 있다는 의견을 제시했습니다. 나 같은 독학 프로그래머는 이 작업을 수행할 수 없습니다. 바이패스 알고리즘에 대한 GPU 코드로 바로 시작하면 바이패스 시간이 오래 걸립니다. 나 자신은 비록 차선책이지만 스스로 이해할 수 있는 간단한 코드로 시작합니다. 그리고 예상한 결과를 얻은 후에야 최적화를 시작합니다. 프로그래머가 아닌 나를 괴롭히는 것 :)
따라서 GPU 컴퓨팅 분야의 전문가의 조언이 필요합니다. 유샤와 JavaDev, 에이!
다음 질문에 관심이 있습니다.
1. 향후 재작업의 번거로움을 피하기 위해 GPU에서 프로젝트 (또는 개별 모듈)를 계산할 가능성(지금까지는 구현이 아닌 가능성만)을 설정할 때 무엇에 먼저 주의해야 합니까?
2. GPU 코어 메모리 제한은 무엇입니까? 원칙적으로 전체 실행 코드를 메모리(수만 및 수십만 막대)의 기록을 통해 별도의 실행에 배치할 수 있습니까?
현재로서는 일반적인 질문입니다. 내가 이해하는 한 더 자세한 내용은 나중에 나올 것입니다.
1. 향후 재작업의 번거로움을 피하기 위해 GPU에서 프로젝트(또는 개별 모듈)를 계산할 가능성(지금까지는 구현이 아닌 가능성만)을 설정할 때 무엇에 먼저 주의해야 합니까?
2. GPU 코어 메모리 제한은 무엇입니까? 원칙적으로 전체 실행 코드를 메모리(수만 및 수십만 막대)의 기록을 통해 별도의 실행에 배치할 수 있습니까?
현재로서는 일반적인 질문입니다. 내가 이해하는 한 더 자세한 내용은 나중에 나올 것입니다.
그리고 광범위하게 사용하기 위한 프로젝트 에서 왜 kuda에 신경을 쓰나요? 일부 사용자는 하나가 있고 다른 사용자는 다른 사용자가 있으며 여전히 다른 사용자는 어디에도 없습니다. 예를 들어, 제 업무용 노트북에는 아무 것도 없습니다. 동일한 네트워크의 코드는 kude의 코어 수와 메모리에 따라 매우 다릅니다. 일반 인텔 프로세서용으로 이 네트워크 엔진을 먼저 작성하여 모든 사람이 사용할 수 있도록 한 다음 타당한 경우 최적화하는 것이 좋습니다. 그건 그렇고 클라우드에서 작동하는 방식으로 엔진을 만드는 것이 좋습니다. 저는 클라우드 컴퓨팅에 익숙하지 않습니다. 과연 어디에 있을까요?
gpwr : 그리고 광범위하게 사용하기 위한 프로젝트에서 왜 kuda에 신경을 쓰나요? 일부 사용자는 하나가 있고 다른 사용자는 다른 사용자가 있으며 여전히 다른 사용자는 어디에도 없습니다. 예를 들어, 제 업무용 노트북에는 아무 것도 없습니다. 동일한 네트워크의 코드는 kude의 코어 수와 메모리에 따라 매우 다릅니다. 일반 인텔 프로세서용으로 이 네트워크 엔진을 먼저 작성하여 모든 사람이 사용할 수 있도록 한 다음 타당한 경우 최적화하는 것이 좋습니다. 그건 그렇고 클라우드에서 작동하는 방식으로 엔진을 만드는 것이 좋습니다. 저는 클라우드 컴퓨팅에 익숙하지 않습니다. 과연 어디에 있을까요?
처음에는 KUDa 없이 프로젝트 를 만들어야 한다는 데 동의합니다. 그러나 게시물에 한 가지 언급이 있습니다. Intel을 연마할 뿐만 아니라 AMD를 잊어서는 안 됩니다.
gpwr : 그리고 광범위하게 사용하기 위한 프로젝트에서 왜 kuda에 신경을 쓰나요? 일부 사용자는 하나가 있고 다른 사용자는 다른 사용자가 있으며 여전히 다른 사용자는 어디에도 없습니다. 예를 들어, 제 업무용 노트북에는 아무 것도 없습니다. 동일한 네트워크의 코드는 kude의 코어 수와 메모리에 따라 매우 다릅니다. 일반 인텔 프로세서용으로 이 네트워크 엔진을 먼저 작성하여 모든 사람이 사용할 수 있도록 한 다음 타당한 경우 최적화하는 것이 좋습니다. 그건 그렇고 클라우드에서 작동하는 방식으로 엔진을 만드는 것이 좋습니다. 저는 클라우드 컴퓨팅에 익숙하지 않습니다. 과연 어디에 있을까요?
MQ는 CUDA(nVidia의 비디오 카드만 해당)가 아니라 OpenCL에 대한 MQL5 지원을 약속했습니다. OpenCL은 CPU와 GPU(AMD 및 nVidia 및 인텔) 모두의 멀티 코어 프로세서가 있는 모든 하드웨어에서 실행할 수 있습니다 . 따라서 CPU 및 GPU 컴퓨팅을 모두 지원 하는 프로젝트 는 모든 사람에게 적합합니다.
???
상관없습니다.
나에게 중요한 것은 발전하고 다른 의견을 듣고 결론을 내리고 싶습니다.
추신 Andrey, 모든 것을 가까이에 두지 마십시오. 항상 옳을 수는 없습니다. 이것이 오픈 소스 프로젝트 가 논쟁하고 증명하는 이유입니다.
GPU Cuda는 강력한 비즈니스입니다. 16개의 Intel 스레드(4코어 프로세서)에서 2-3시간 동안 실행되는 코드가 있었습니다. 그리고 300개 이상의 CUDA 코어에서 10분 만에 같은 거리를 달리는 것이 인상적이었습니다. 그러나 Kudo 코드의 개발은 매우 어려웠습니다. 코드의 모든 계산을 수동으로 병렬 스레드로 나누고 메모리를 최적화해야 했습니다(안타깝게도 Kudo 코어에는 거의 없음). 나는 이것을 할 수 없었다 - 똑똑한 프로그래머가 도왔다. 나는 여전히 그의 코드를 두려워하고 내 원래(비병렬) 코드에서 모든 변경을 계속합니다. 나는 알고리즘이 안정적이라면 유능한 프로그래머의 도움으로 최적화되어 GPU로 전송될 수 있다는 의견을 제시했습니다. 나 같은 독학 프로그래머는 이 작업을 수행할 수 없습니다. 바이패스 알고리즘에 대한 GPU 코드로 바로 시작하면 바이패스 시간이 오래 걸립니다. 나 자신은 비록 차선책이지만 스스로 이해할 수 있는 간단한 코드로 시작합니다. 그리고 예상한 결과를 얻은 후에야 최적화를 시작합니다. 프로그래머가 아닌 나를 괴롭히는 것 :)
GPU Cuda는 강력한 비즈니스입니다. 16개의 Intel 스레드(4코어 프로세서)에서 2-3시간 동안 실행되는 코드가 있었습니다. 그리고 300개 이상의 CUDA 코어에서 10분 만에 같은 거리를 달리는 것이 인상적이었습니다. 그러나 Kudo 코드의 개발은 매우 어려웠습니다. 코드의 모든 계산을 수동으로 병렬 스레드로 나누고 메모리를 최적화해야 했습니다(안타깝게도 Kudo 코어에는 거의 없음). 나는 이것을 할 수 없었다 - 똑똑한 프로그래머가 도왔다. 나는 여전히 그의 코드를 두려워하고 내 원래(비병렬) 코드에서 모든 변경을 계속합니다. 나는 알고리즘이 안정적이라면 유능한 프로그래머의 도움으로 최적화되어 GPU로 전송될 수 있다는 의견을 제시했습니다. 나 같은 독학 프로그래머는 이 작업을 수행할 수 없습니다. 바이패스 알고리즘에 대한 GPU 코드로 바로 시작하면 바이패스 시간이 오래 걸립니다. 나 자신은 비록 차선책이지만 스스로 이해할 수 있는 간단한 코드로 시작합니다. 그리고 예상한 결과를 얻은 후에야 최적화를 시작합니다. 프로그래머가 아닌 나를 괴롭히는 것 :)
따라서 GPU 컴퓨팅 분야의 전문가의 조언이 필요합니다. 유샤와 JavaDev , 에이!
다음 질문에 관심이 있습니다.
1. 향후 재작업의 번거로움을 피하기 위해 GPU에서 프로젝트 (또는 개별 모듈)를 계산할 가능성(지금까지는 구현이 아닌 가능성만)을 설정할 때 무엇에 먼저 주의해야 합니까?
2. GPU 코어 메모리 제한은 무엇입니까? 원칙적으로 전체 실행 코드를 메모리(수만 및 수십만 막대)의 기록을 통해 별도의 실행에 배치할 수 있습니까?
현재로서는 일반적인 질문입니다. 내가 이해하는 한 더 자세한 내용은 나중에 나올 것입니다.
따라서 GPU 컴퓨팅 분야의 전문가의 조언이 필요합니다. 유샤와 JavaDev , 에이!
다음 질문에 관심이 있습니다.
1. 향후 재작업의 번거로움을 피하기 위해 GPU에서 프로젝트(또는 개별 모듈)를 계산할 가능성(지금까지는 구현이 아닌 가능성만)을 설정할 때 무엇에 먼저 주의해야 합니까?
2. GPU 코어 메모리 제한은 무엇입니까? 원칙적으로 전체 실행 코드를 메모리(수만 및 수십만 막대)의 기록을 통해 별도의 실행에 배치할 수 있습니까?
현재로서는 일반적인 질문입니다. 내가 이해하는 한 더 자세한 내용은 나중에 나올 것입니다.
그리고 광범위하게 사용하기 위한 프로젝트에서 왜 kuda에 신경을 쓰나요? 일부 사용자는 하나가 있고 다른 사용자는 다른 사용자가 있으며 여전히 다른 사용자는 어디에도 없습니다. 예를 들어, 제 업무용 노트북에는 아무 것도 없습니다. 동일한 네트워크의 코드는 kude의 코어 수와 메모리에 따라 매우 다릅니다. 일반 인텔 프로세서용으로 이 네트워크 엔진을 먼저 작성하여 모든 사람이 사용할 수 있도록 한 다음 타당한 경우 최적화하는 것이 좋습니다. 그건 그렇고 클라우드에서 작동하는 방식으로 엔진을 만드는 것이 좋습니다. 저는 클라우드 컴퓨팅에 익숙하지 않습니다. 과연 어디에 있을까요?
그리고 광범위하게 사용하기 위한 프로젝트에서 왜 kuda에 신경을 쓰나요? 일부 사용자는 하나가 있고 다른 사용자는 다른 사용자가 있으며 여전히 다른 사용자는 어디에도 없습니다. 예를 들어, 제 업무용 노트북에는 아무 것도 없습니다. 동일한 네트워크의 코드는 kude의 코어 수와 메모리에 따라 매우 다릅니다. 일반 인텔 프로세서용으로 이 네트워크 엔진을 먼저 작성하여 모든 사람이 사용할 수 있도록 한 다음 타당한 경우 최적화하는 것이 좋습니다. 그건 그렇고 클라우드에서 작동하는 방식으로 엔진을 만드는 것이 좋습니다. 저는 클라우드 컴퓨팅에 익숙하지 않습니다. 과연 어디에 있을까요?
MQ는 CUDA(nVidia의 비디오 카드만 해당)가 아니라 OpenCL에 대한 MQL5 지원을 약속했습니다. OpenCL은 CPU와 GPU(AMD 및 nVidia 및 인텔) 모두의 멀티 코어 프로세서가 있는 모든 하드웨어에서 실행할 수 있습니다 . 따라서 CPU 및 GPU 컴퓨팅을 모두 지원 하는 프로젝트 는 모든 사람에게 적합합니다.
MQL5는 OpenCL을 지원하므로 클라우드 에이전트도 GPU 컴퓨팅을 지원할 것입니다.
우크라이나 :
항상 옳다는 것은 불가능합니다. 그래서 오픈 소스 프로젝트는 주장하고 증명하는 것입니다.
따라서 GPU 컴퓨팅 분야의 전문가의 조언이 필요합니다. 유샤와 JavaDev , 에이!
다음 질문에 관심이 있습니다.
1. 향후 재작업의 번거로움을 피하기 위해 GPU에서 프로젝트(또는 개별 모듈)를 계산할 가능성(지금까지는 구현이 아닌 가능성만)을 설정할 때 무엇에 먼저 주의해야 합니까?
2. GPU 코어 메모리 제한은 무엇입니까? 원칙적으로 전체 실행 코드를 메모리(수만 및 수십만 막대)의 기록을 통해 별도의 실행에 배치할 수 있습니까?
현재로서는 일반적인 질문입니다. 내가 이해하는 한 더 자세한 내용은 나중에 나올 것입니다.
하이라이트:
1) GPU는 훈련용으로만 필요합니다.
2) 한 계층의 뉴런 값을 병렬로 계산 하고 수백 개의 네트워크를 동시에 실행하여 더 중요한 것은 성능이 크게 향상됩니다.
프로젝트를 자율 구성 요소로 최대한 분해 -주의해야 할 사항입니다.
GPU의 DDR 메모리는 수십만 막대의 기록을 저장하기에 충분합니다.
커널 메모리는 매우 제한적입니다(30-50KB). 프로그래밍의 직접 처리는 또한 이 문제를 해결합니다. 칩의 메모리가 코어 주파수에서 작동하고 액세스 비용이 0주기이기 때문에 그만한 가치가 있습니다. 핵 메모리 뱅크의 갈등도 있고 우회하기도 한다.
Windows 기능과 관련된 불쾌한 순간이 있습니다. 한 번의 실행이 5초 이상 지속되면 드라이버가 재설정됩니다.
따라서 달성된 최대값: 100,000개의 히스토리 막대당 ~ 100개의 뉴런으로 구성된 100-200개의 네트워크 훈련
이 (최대) 구성을 사용하면 GTX 460 GPU에서 초당 ~ 20-30 실행의 최적화 속도를 얻을 수 있습니다.