모든 것이 훌륭하지만! 일반적으로 OCL과 모든 병렬화 도구에는 큰 문제가 있습니다. 알고리즘의 아주 작은 부분을 효과적으로 병렬화할 수 있습니다. 병렬 컴퓨팅 의 예에서 파도의 모방, 피라미드에 공이 떨어지는 것과 파괴되는 것, 즉 작은 입자로 쪼개질 수 있고 각각이 자체적으로 계산될 수 있는 모든 것이 그렇게 사랑받는 이유는 무엇입니까?
핸디캡/익스체인지에서는 물론 신경망, 푸리에, 웨이블릿, 필터 등과 같은 다양한 변환이며 모두 완벽하게 병렬입니다. 그러나 병렬화할 수 없는 선형 알고리즘이 있습니다. 일반적으로 알고리즘의 다음 단계의 결과가 이전 단계의 결과를 기반으로 하는 경우입니다.
나는 이제 2개의 멋진 비디오를 사고 모든 것이 내 테스터에서 날아갈 것이라고 생각하는 사람들을 위해 이것을 썼습니다.
바로 어제 나는 거래에서 그것을 어디에 묶을 것인지 이해하기 위해 이것을 논의하고 있었습니까? 파도 바다 - 모든 것이 아름답지만 무역과는 전혀 관련이 없습니다. 그리고 여기에 사람들이 무역을 위해 정확히 그를 위해 모인 것처럼 보입니다. 얼마나 많은 사람들이 NS를 사용하게 됩니까? 2.5명? MO에 관한 지점에서 그 번호가 완벽하게 표시되지만 모든 사람이 국회를 이용하는 것은 아닙니다.
모든 것이 훌륭하지만! 일반적으로 OCL과 모든 병렬화 도구에는 큰 문제가 있습니다. 알고리즘의 아주 작은 부분을 효과적으로 병렬화할 수 있습니다. 병렬 컴퓨팅 의 예에서 파동의 모방, 파괴와 함께 피라미드에 공이 떨어지는 것, 즉 작은 입자로 쪼개질 수 있고 각각이 자체 프로세스에 따라 계산되는 모든 것이 그렇게 사랑받는 이유는 무엇입니까?
핸디캡/익스체인지에서는 물론 신경망, 푸리에, 웨이블릿, 필터 등과 같은 다양한 변환이며 모두 완벽하게 병렬입니다. 그러나 병렬화할 수 없는 선형 알고리즘이 있습니다. 일반적으로 알고리즘의 다음 단계의 결과가 이전 단계의 결과를 기반으로 하는 경우입니다.
나는 이제 2개의 멋진 비디오를 사고 모든 것이 내 테스터에서 날아갈 것이라고 생각하는 사람들을 위해 이것을 썼습니다.
Expert Advisor의 내부 로직이 병렬화되지 않은 경우, 전체 Expert Advisor, 하나의 스레드 - 하나의 Expert Advisor를 병렬화하는 것이 가능합니다. 이것이 일반적으로 클라우드와 에이전트가 작동하는 방식입니다. 하나의 스레드 == 하나의 조언자 == 하나의 역사를 통해 실행, 나는 그러한 병렬화의 예를 들었습니다.
예를 들어, 이 접근 방식을 사용하면 특별한 문제 없이 자체 제작한 최적화 프로그램에서 상당한 가속을 달성할 수 있을 뿐만 아니라 클라우드에서 일반적인 최적화의 일부로 내부 자체 최적화를 수행하는 것이 가능해집니다(예: 내부 롤포워드). 물론, 아무도 각 스레드 내에서 추가 병렬화를 사용하는 것을 금지하지 않습니다(내 예에서는 가능성이 있지만 이것을 하지 않았습니다). 따라서 최적화와 관련하여 항상 병렬화할 수 있는 것이 항상 있다고 말할 수 있습니다.
어드바이저의 내부 로직이 병렬화되지 않은 경우, 전체 어드바이저, 하나의 스레드 - 하나의 어드바이저 를 병렬화하는 것이 가능합니다. 이것이 일반적으로 클라우드와 에이전트가 작동하는 방식입니다. 하나의 스레드 == 하나의 조언자 == 하나의 역사를 통해 실행, 나는 그러한 병렬화의 예를 들었습니다.
예를 들어, 이 접근 방식을 사용하면 특별한 문제 없이 자체 제작한 최적화 프로그램에서 상당한 가속을 달성할 수 있을 뿐만 아니라 클라우드에서 일반적인 최적화의 일부로 내부 자체 최적화를 수행하는 것이 가능해집니다(예: 내부 롤포워드). 물론, 아무도 각 스레드 내에서 추가 병렬화를 사용하는 것을 금지하지 않습니다(내 예에서는 가능성이 있지만 이것을 하지 않았습니다). 따라서 최적화와 관련하여 항상 병렬화할 수 있는 것이 항상 있다고 말할 수 있습니다.
맞습니다. 하지만 강조 표시된 부분이 OCL과 어떤 관련이 있습니까? 이것은 옵티마이저 개발자의 임무입니다. 클라우드에서와 같이 GPU에서 최적화를 보장하는 것입니다. 아니면 OCL 스레드로 실행되는 Expert Advisor 주변에 래퍼를 작성하는 것입니까? 오늘날의 옵티마이저는 그러한 움직임을 이해하지 못할 것입니다.
오늘날에는 자신의 최적화 프로그램을 작성하는 것이 남아 있습니다. 여기에서 무엇이든 할 수 있습니다.
일반적으로 포스트의 의미는 프로그래머가 아니거나 초보자가 대부분인 정신을 차리고 불필요한 환상을 박탈하는 것이었습니다.
맞습니다. 하지만 강조 표시된 부분이 OCL과 어떤 관련이 있습니까? 이것은 옵티마이저 개발자의 임무입니다. 클라우드에서와 같이 GPU에서 최적화를 보장하는 것입니다. 아니면 OCL 스레드로 실행되는 Expert Advisor 주변에 래퍼를 작성하는 것입니까? 오늘날의 옵티마이저는 그러한 움직임을 이해하지 못할 것입니다.
오늘날에는 자신의 최적화 프로그램을 작성하는 것이 남아 있습니다. 여기에서 무엇이든 할 수 있습니다.
일반적으로 포스트의 의미는 프로그래머가 아니거나 초보자가 대부분인 정신을 차리고 불필요한 환상을 박탈하는 것이었습니다.
전체 EA 로직이 테스트 중인 히스토리와 함께 OCL 장치로 전송되는 예를 드렸습니다( 하나의 스레드 == 하나의 EA == 하나의 히스토리 실행) . 이 결정은 테스터와 옵티마이저 모두가 이해합니다. 물론 이것은 프로그래머를 위한 솔루션입니다.
그리고 일반 사용자의 경우 - 예, oblamingo, 그들은 고문의 혁신으로부터 가속을 받지 못할 것입니다. 개발자가 전체 어드바이저를 셰이더와 같은 재컴파일된 특정 프로그램의 형태로 OCL 장치에 보낼 수 있는 경우에만 가능하지만 아직 논의되지 않았습니다.
모든 것이 훌륭하지만! 일반적으로 OCL과 모든 병렬화 도구에는 큰 문제가 있습니다. 알고리즘의 아주 작은 부분을 효과적으로 병렬화할 수 있습니다. 병렬 컴퓨팅 의 예에서 파도의 모방, 피라미드에 공이 떨어지는 것과 파괴되는 것, 즉 작은 입자로 쪼개질 수 있고 각각이 자체적으로 계산될 수 있는 모든 것이 그렇게 사랑받는 이유는 무엇입니까?
핸디캡/익스체인지에서는 물론 신경망, 푸리에, 웨이블릿, 필터 등과 같은 다양한 변환이며 모두 완벽하게 병렬입니다. 그러나 병렬화할 수 없는 선형 알고리즘이 있습니다. 일반적으로 알고리즘의 다음 단계의 결과가 이전 단계의 결과를 기반으로 하는 경우입니다.
나는 이제 2개의 멋진 비디오를 사고 모든 것이 내 테스터에서 날아갈 것이라고 생각하는 사람들을 위해 이것을 썼습니다.
바로 어제 나는 거래에서 그것을 어디에 묶을 것인지 이해하기 위해 이것을 논의하고 있었습니까? 파도 바다 - 모든 것이 아름답지만 무역과는 전혀 관련이 없습니다. 그리고 여기에 사람들이 무역을 위해 정확히 그를 위해 모인 것처럼 보입니다. 얼마나 많은 사람들이 NS를 사용하게 됩니까? 2.5명? MO에 관한 지점에서 그 번호가 완벽하게 표시되지만 모든 사람이 국회를 이용하는 것은 아닙니다.
모든 것이 훌륭하지만! 일반적으로 OCL과 모든 병렬화 도구에는 큰 문제가 있습니다. 알고리즘의 아주 작은 부분을 효과적으로 병렬화할 수 있습니다. 병렬 컴퓨팅 의 예에서 파동의 모방, 파괴와 함께 피라미드에 공이 떨어지는 것, 즉 작은 입자로 쪼개질 수 있고 각각이 자체 프로세스에 따라 계산되는 모든 것이 그렇게 사랑받는 이유는 무엇입니까?
핸디캡/익스체인지에서는 물론 신경망, 푸리에, 웨이블릿, 필터 등과 같은 다양한 변환이며 모두 완벽하게 병렬입니다. 그러나 병렬화할 수 없는 선형 알고리즘이 있습니다. 일반적으로 알고리즘의 다음 단계의 결과가 이전 단계의 결과를 기반으로 하는 경우입니다.
나는 이제 2개의 멋진 비디오를 사고 모든 것이 내 테스터에서 날아갈 것이라고 생각하는 사람들을 위해 이것을 썼습니다.
Expert Advisor의 내부 로직이 병렬화되지 않은 경우, 전체 Expert Advisor, 하나의 스레드 - 하나의 Expert Advisor를 병렬화하는 것이 가능합니다. 이것이 일반적으로 클라우드와 에이전트가 작동하는 방식입니다. 하나의 스레드 == 하나의 조언자 == 하나의 역사를 통해 실행, 나는 그러한 병렬화의 예를 들었습니다.
예를 들어, 이 접근 방식을 사용하면 특별한 문제 없이 자체 제작한 최적화 프로그램에서 상당한 가속을 달성할 수 있을 뿐만 아니라 클라우드에서 일반적인 최적화의 일부로 내부 자체 최적화를 수행하는 것이 가능해집니다(예: 내부 롤포워드). 물론, 아무도 각 스레드 내에서 추가 병렬화를 사용하는 것을 금지하지 않습니다(내 예에서는 가능성이 있지만 이것을 하지 않았습니다). 따라서 최적화와 관련하여 항상 병렬화할 수 있는 것이 항상 있다고 말할 수 있습니다.
어드바이저의 내부 로직이 병렬화되지 않은 경우, 전체 어드바이저, 하나의 스레드 - 하나의 어드바이저 를 병렬화하는 것이 가능합니다. 이것이 일반적으로 클라우드와 에이전트가 작동하는 방식입니다. 하나의 스레드 == 하나의 조언자 == 하나의 역사를 통해 실행, 나는 그러한 병렬화의 예를 들었습니다.
예를 들어, 이 접근 방식을 사용하면 특별한 문제 없이 자체 제작한 최적화 프로그램에서 상당한 가속을 달성할 수 있을 뿐만 아니라 클라우드에서 일반적인 최적화의 일부로 내부 자체 최적화를 수행하는 것이 가능해집니다(예: 내부 롤포워드). 물론, 아무도 각 스레드 내에서 추가 병렬화를 사용하는 것을 금지하지 않습니다(내 예에서는 가능성이 있지만 이것을 하지 않았습니다). 따라서 최적화와 관련하여 항상 병렬화할 수 있는 것이 항상 있다고 말할 수 있습니다.
맞습니다. 하지만 강조 표시된 부분이 OCL과 어떤 관련이 있습니까? 이것은 옵티마이저 개발자의 임무입니다. 클라우드에서와 같이 GPU에서 최적화를 보장하는 것입니다. 아니면 OCL 스레드로 실행되는 Expert Advisor 주변에 래퍼를 작성하는 것입니까? 오늘날의 옵티마이저는 그러한 움직임을 이해하지 못할 것입니다.
오늘날에는 자신의 최적화 프로그램을 작성하는 것이 남아 있습니다. 여기에서 무엇이든 할 수 있습니다.
일반적으로 포스트의 의미는 프로그래머가 아니거나 초보자가 대부분인 정신을 차리고 불필요한 환상을 박탈하는 것이었습니다.
맞습니다. 하지만 강조 표시된 부분이 OCL과 어떤 관련이 있습니까? 이것은 옵티마이저 개발자의 임무입니다. 클라우드에서와 같이 GPU에서 최적화를 보장하는 것입니다. 아니면 OCL 스레드로 실행되는 Expert Advisor 주변에 래퍼를 작성하는 것입니까? 오늘날의 옵티마이저는 그러한 움직임을 이해하지 못할 것입니다.
오늘날에는 자신의 최적화 프로그램을 작성하는 것이 남아 있습니다. 여기에서 무엇이든 할 수 있습니다.
일반적으로 포스트의 의미는 프로그래머가 아니거나 초보자가 대부분인 정신을 차리고 불필요한 환상을 박탈하는 것이었습니다.
전체 EA 로직이 테스트 중인 히스토리와 함께 OCL 장치로 전송되는 예를 드렸습니다( 하나의 스레드 == 하나의 EA == 하나의 히스토리 실행) . 이 결정은 테스터와 옵티마이저 모두가 이해합니다. 물론 이것은 프로그래머를 위한 솔루션입니다.
그리고 일반 사용자의 경우 - 예, oblamingo, 그들은 고문의 혁신으로부터 가속을 받지 못할 것입니다. 개발자가 전체 어드바이저를 셰이더와 같은 재컴파일된 특정 프로그램의 형태로 OCL 장치에 보낼 수 있는 경우에만 가능하지만 아직 논의되지 않았습니다.
전체 EA 로직이 테스트 중인 히스토리와 함께 OCL 장치로 전송되는 예를 드렸습니다( 하나의 스레드 == 하나의 EA == 하나의 히스토리 실행) . 이 결정은 테스터와 옵티마이저 모두가 이해합니다. 물론 이것은 프로그래머를 위한 솔루션입니다.
그리고 일반 사용자의 경우 - 예, oblamingo, 그들은 고문의 혁신으로부터 가속을 받지 못할 것입니다. 개발자 가 전체 어드바이저를 셰이더와 같은 재컴파일된 특정 프로그램의 형태로 OCL 장치에 보낼 수 있는 경우에만 가능하지만 아직 논의되지 않았습니다.
예를 들자면 아직 판단할 수 없고 OCL이 살아있다는 느낌을 받아야 하는데 그게 중요한 것 같다.
그러나 선택에서는 믿기 어렵습니다. MQ는 OCL에서 MQL API, 특히거래 기능 , 시계열에 대한 액세스, 지표에 대한 액세스를 가져올 수 있도록 몇 가지 브리지를 작성해야 합니다.
예를 들자면 아직 판단할 수 없고 OCL이 살아있다는 느낌을 받아야 하는데 그게 중요한 것 같다.
그러나 선택에서는 믿기 어렵습니다. MQ는 OCL 에서 MQL API, 특히 거래 기능 , 시계열에 대한 액세스, 지표에 대한 액세스를 가져올 수 있도록 몇 가지 브리지를 작성해야 합니다.
네, 맞습니다. 하지만 1995년에 메타에디터가 "메모장" 수준에 머물러 있다는 사실이 상당히 안타깝고, 2017년이 코앞에 와 있음에도 불구하고 말입니다. 그들은 무언가를 하지만 이를 위해 무언가를 작성하려면 고대 편집기에서 작성해야 합니다.
개발자 여러분, 마침내 메모장에서처럼 최소한 일치하는 항목을 강조 표시하십시오!
모든 것이 훌륭하지만! 일반적으로 OCL과 모든 병렬화 도구에는 큰 문제가 있습니다. 알고리즘의 아주 작은 부분을 효과적으로 병렬화할 수 있습니다.
와, 간단합니다. 알고리즘이 병렬이든 아니든 생각할 필요가 없습니다. 접근 방식은 다음과 같습니다. 알고리즘을 보고 - 주기를 보고 -> 이미 병렬화될 수 있다고 생각합니다(높은 확률). 주기 없음 - 걱정할 이유가 없습니다.
네, 맞습니다. 하지만 1995년에 메타에디터가 "메모장" 수준에 머물러 있다는 사실이 상당히 안타깝고, 2017년이 코앞에 와 있음에도 불구하고 말입니다. 그들은 무언가를 하지만 이를 위해 무언가를 작성하려면 고대 편집기에서 작성해야 합니다.
개발자 여러분, 마침내 메모장에서처럼 최소한 일치하는 항목을 강조 표시하십시오!
예, 틱이 원시라는 사실에 대해 이미 여기에 2개의 게시물을 작성했습니다. 제거됨. 그리고 당신의 글은 삭제될 것입니다. 관리자/조정자는 이 스레드에서 MQ 단점을 언급할 필요가 없습니다. 역병 시대의 잔치...
어떻게 든 자동차를 칠하고 티타늄 디스크와 모든 종류의 불필요한 장신구를 넣을 때와 비슷하지만 자동차의 엔진 자체가 그 전에 "노크"하고 막혔습니다. 즉, 차가 고장 났기 때문에 모두 불필요합니다.
여기 저기 쓰기용 로션이 잔뜩 있는데 이걸 다 써야 하는 곳은 1995년 수준이고, 코드가 200줄 이상으로 구성되면 완전 고된 노동이다.
동시에 존경받는 Renat는 다음과 같이 씁니다.
불행히도 Windows XP에서는 OpenCL을 잊어버려야 합니다. 그리고 일반적으로 약 32비트 운영 체제 - 2017년이 코앞 입니다.
그렇다면 2016 메타 에디터는 어디에 있습니까?
최소한 코드 강조 표시 를 만드십시오. 그러나 시간이 지남에 따라 가능하면 접습니다!
어떻게 든 자동차를 칠하고 티타늄 디스크와 모든 종류의 불필요한 장신구를 넣을 때와 비슷하지만 자동차의 엔진 자체가 그 전에 "노크"하고 막혔습니다. 즉, 차가 고장 났기 때문에 모두 불필요합니다.
여기 저기 쓰기용 로션이 잔뜩 있는데 이걸 다 써야 하는 곳은 1995년 수준이고, 코드가 200줄 이상으로 구성되면 완전 고된 노동이다.
동시에 존경받는 Renat는 다음과 같이 씁니다.
그렇다면 2016 메타 에디터는 어디에 있습니까?
최소한 코드 강조 표시 를 만드십시오. 그러나 시간이 지남에 따라 가능하면 접습니다!