조금 놀랐습니다 :) 저는 수사학적 질문을 하지 않고 공유하기로 결정했습니다. - 페이지 14

 
Renat :

옵티마이저는 정확히 "선형 확장 테스터"가 아니지만 대규모 반복 계산에서 효과적으로 작동하는 자체 최적화 방법을 가지고 있습니다.

우리는 지금 대량 계산에 박차를 가하고 있습니다. 여기에 과거 결과에 대한 링크가 있으며 더 빠른 계산이 가능한 새 버전이 이미 준비되어 있습니다.

정확히 "선형 확장 테스터"가 아니라는 데 동의합니다. 명시적 최적화를 수행하고 있습니다. 이는 매우 좋은 일입니다. 그러나 보편적 인 경우에 대해 매우 일반적인 상황에 대해 어떻게 최적화하는지 알 수 없습니다.

최적화는 두 개의 매개변수를 기반으로 합니다. 하나의 매개변수(100개 값 범위)는 표시기 호출에 적용되지 않고 두 번째 매개변수(5개 값 범위)는 적용됩니다.

이 경우 500개 이상의 옵션을 반복할 때 지표 값을 500번 계산하게 됩니다. 이 경우 실제로 엄청난 양의 반복 계산이 발생합니다. 두 번째 변수의 범위는 500이 아니라 5이기 때문입니다.

이것은 가장 간단한 예일 뿐입니다. 아마도 당신은 옵티마이저를 위한 테스터의 그러한 선형 확장성을 회피하는 방법에 대한 몇 가지 아이디어를 이미 가지고 있을 것입니다.

추신 속도에 있어서 그들의 운율의 이점은 백분율이 아니라 크기의 순서로 얻어지는 것과 같은 예에서입니다. 그러나 이러한 운율은 보편적이지 않으므로 처음에는 비교가 잘못되었습니다.

 
Academic :

좋아 - 클라우드 컴퓨팅이 아니라 다중 스레드이고 C ++ 및 MT4(및 전체 하위 시스템)를 지원하고 그것보다 100배 빠르며 순수하게 MT5에 따르면 6배 빠른 옵티마이저가 있다고 가정해 보겠습니다. code, yes ... 그리고 "해결"은 열거 및 GA뿐만 아니라 약 50가지의 추가 옵션으로 해결됩니다. 얼마에 사시겠습니까? 1000원에 사시겠습니까? 왜 그렇게 비싼가요? 예, 당신과 다른 10명이 구매자를 깨울 것입니다. :)

옵티마이저가 보편적이고 그러한 특성을 가지고 있다면 나는 그것을 살 것입니다.
 
hrenfx :

그러나 보편적 인 경우에 대해 매우 일반적인 상황에 대해 어떻게 최적화하는지 알 수 없습니다.

이미 내가 대표하는 것입니다(그러나 끝까지는 아님). 옵티마이저를 실행하기 전에 최적화된 입력 매개변수의 종속성을 분석해야 합니다(위의 예에서 두 변수는 완전히 독립적임). 또한, 가장 작은 범위에서 가장 큰 범위까지 독립 변수에 대해 최적화를 먼저 수행해야 합니다(동일한 표시기의 리소스 강도에 따라 달라지기 때문에 항상 정확하지는 않습니다. 때로는 조명 표시기를 5보다 100배 계산하는 것이 더 좋습니다. 무거운 것), 결과를 캐싱합니다.

그러한 최적화의 구현은 매우 복잡합니다(특히 클라우드의 경우). 그러나 구현하면 MQL5 마법사에서 생성된 모든 Expert Advisors가 최소한 절대적으로 훨씬 빠르게 최적화됩니다. MQL5 마법사는 수많은 지표가 서로 결합되어 있기 때문입니다(즉, 수많은 독립 입력 매개변수가 있음). 또 다른 것은 그러한 활동이 수익성있는 거래에 의미가 없다는 것입니다 ...

 

거대한(수백만 및 수천만) 샘플의 결과를 후속적으로 가져오는 캐싱은 직접 계산보다 비용이 더 많이 듭니다.

 
Renat :

거대한(수백만 및 수천만) 샘플의 결과를 후속적으로 가져오는 캐싱은 직접 계산보다 비용이 더 많이 듭니다.

위에서 설명한 것처럼 "지능적"이 되도록 이상적으로는 보편적인 옵티마이저를 구현하는 것이 거의 불가능하다고 확신합니다. 물론 개선의 여지가 있지만 어떤 경우에도 완벽하게 작동하지는 않습니다.

물론 거대한 샘플(수천만 개)은 크게 과장했습니다. 이것을 캐시할 필요가 전혀 없습니다.

제 말의 의미를 모두 완벽하게 이해하셨으리라 생각합니다. 그리고 많은 사람들이 이해합니다. 아무도 이것에 대해 비판하지 않을 것입니다. 그렇지 않으면 비평가에 대한 프로그래머의 무지가 될 것입니다. 적절한 사람들은 이것을 구현하는 복잡성을 완벽하게 이해하고 있기 때문입니다.

캐싱에 관해서는 동일한 예를 사용하여 모든 것을 설명하겠습니다.

표시기가 다시 그려지지 않으면 테스터에서 다음 단일 실행이 끝날 때까지 모든 표시기 값의 전체 버퍼를 갖게 됩니다. 당신은 이미 그것을 가지고 있습니다. 그리고 다음 패스가 동일한 지표 값을 모두 사용하는 경우(두 번째 변수는 변경되지 않음) 다시 계산할 필요가 없습니다. 이미 계산된 버퍼에서 값을 가져올 수 있습니다(이미 존재하므로 캐시할 필요가 없습니다. 이전 실행의 메모리가 완전히 해제되지 않았기 때문입니다).

 
hrenfx :

표시기가 다시 그려지지 않으면

이 "if"는 모든 추가 검색을 무효화합니다.
 
네, 정확히 그러한 스마트 범용 최적화 프로그램을 작성할 수 없기 때문에 비범용 숫자 분쇄기가 속도 면에서 항상 승리할 것입니다. 그리고 여기에는 좋고 나쁨이 없습니다.
 
hrenfx :

위에서 설명한 것처럼 "지능적"이 되도록 이상적으로는 보편적인 옵티마이저를 구현하는 것이 거의 불가능하다고 확신합니다. 물론 개선의 여지가 있지만 어떤 경우에도 완벽하게 작동하지는 않습니다.

물론 거대한 샘플(수천만 개)은 크게 과장했습니다. 이것을 캐시할 필요가 전혀 없습니다.

예를 들어, 지난 11년 동안의 EURUSD 테스트는 5천만 개 이상의 틱을 제공합니다.

이는 MA 유형의 단순한 단일 버퍼 표시기의 경우 5천만 개의 상태를 저장해야 함을 의미합니다(5천만 * 8바이트(이중) = 400MB 버퍼). 이는 많은 양입니다. 더 복잡하거나 더 큰 것이 사용되면 실제로 캐시는 멀티 코어 에이전트는 말할 것도 없고 메모리에 맞지 않습니다.

우리는 표시기 캐시에 대한 아이디어를 연구하고 있었고 표시기의 다음 값을 계산하는 것(그리고 경제적인 방법을 사용하여)이 캐시를 구축하는 것보다 훨씬 빠르고 리소스 집약적인 것으로 나타났습니다.

 
hrenfx :
네, 정확히 그러한 스마트 범용 최적화 프로그램을 작성할 수 없기 때문에 비범용 숫자 분쇄기가 속도 면에서 항상 승리할 것입니다. 그리고 여기에는 좋고 나쁨이 없습니다.

그들은 아무것도 얻지 못합니다.

그들은 시장 환경도, 인프라도, 지표도, 분석 도구도 없습니다. 그리고 이것은 일회성 사이클보다 더 중요합니다.

 
Renat :

예를 들어, 지난 11년 동안의 EURUSD 테스트는 5천만 개 이상의 틱을 제공합니다.

우리는 테스터의 단일 실행 세트가 아니라 옵티마이저에 대해 이야기하고 있습니다. 옵티마이저의 개념은 완전히 다릅니다. 결과의 사소한 오류로 인해 속도가 크게 향상됩니다. 옵티마이저는 틱 모델이 전혀 필요하지 않습니다. 최대 - 시가 기준. 옵티마이저는 여러 번 테스터가 아니라 완전히 다른 것입니다. 당신은 다른 접근 방식을 가지고 있으며 매우 논리적입니다.

레나트 :

그들은 아무것도 얻지 못합니다.

그들은 시장 환경도, 인프라도, 지표도, 분석 도구도 없습니다. 그리고 이것은 일회성 사이클보다 더 중요합니다.

for 루프보다 더 빠른 것은 없기 때문에 속도 면에서 승리합니다. 때때로 필요한 것은 속도이며, 운율은 속도 측면에서 모든 범용 테스터를 능가합니다(그러나 다른 매개변수에서는 그렇지 않음). MetaQuotes뿐만 아니라.

다음과 같은 이유로 내 진술을 증명할 수 없습니다.

내 운은 내 Expert Advisor의 C++ 구현일 뿐입니다. 여기서 모든 작업은 특별히 정수(가격은 정수)로 만들어지고 추가 패스는 완전히 0으로 줄이는 등입니다. 인터페이스도 없고 아무것도 없습니다. 최적화 결과 가 있는 출력 파일만. 저것들. 나는 C++에서 알고리즘 최적화를 사용하여 EA를 작성할 수 있으며 내 테스터는 거래 확인(충분한 마진이 있는지 여부 등)을 하지 않을 것입니다. 기록을 에뮬레이트하지 않으며 지표를 계산하지 않습니다. MT5 테스터의 다양성 측면에서 보편적인 것은 없습니다. 카운팅 운율의 작업은 가능한 한 빨리 빨리 계산하는 것입니다. 그리고 MT4 테스터보다 100배 빠르게 계산하여 < 1%의 오류를 제공합니다. 내 쪽에서 보여줄 것이 전혀 명확하지 않습니다.

검사가 없고 정수만 있는 for 루프가 유니버설 테스터보다 항상 더 빠르게 계산된다는 것은 분명합니다.

사유: