전략 테스터의 최적화 - 페이지 16

 
Renat :

최신 빌드에서는 작업 시작 시 시스템 오버헤드를 완전히 제거하여 거의 2000ms에서 0으로 줄였습니다.

joo가 제안한 계산 작업을 실행한 결과는 다음과 같습니다.

설정(날짜는 차트 기록이 사용되지 않도록 특별히 설정됨):

반복 매개변수:

사용된 에이전트(로컬 에이전트 4개):

최적화 결과:

최적화는 단 25초만에 완료되었으며 18,432개의 패스가 생성되었습니다.

거래 전략 테스터를 최적화하는 이전 작업 으로 돌아갑니다.

425 빌드에 대한 전체 계획의 개선 사항은 다음과 같습니다.

  • 패스 준비를 위한 시스템 오버헤드 감소
  • 설정을 단순화한 시뮬레이션 유형 선택에 명시적 모드 "수학 계산" 추가

다음은 빌드 425에서 동일한 하드웨어(4개의 로컬 에이전트) 및 깨끗한 캐시에 대한 결과입니다.

Tester	optimization passed in 0 minutes 07 seconds
Tester	genetic optimization finished on pass 19456 (of 100000020000001)
Tester	result cache was used 10124 times
Tester	genetics is over

원래 제기된 질문 (오버헤드는 패스당 2초)과 비교하여 문제를 성공적으로 해결했습니다. 25초 대신 동일한 작업을 7초로 간주했습니다.

태스크 번들링은 시스템 오버헤드를 방지하기 위한 기초가 되었습니다. 이제 각 에이전트에 대해 처리 속도가 측정되고 계산을 위해 1에서 64까지의 작업 팩이 발행됩니다. 결과적으로 테스트를 준비하고 결과를 얻는 데 걸리는 시간이 그에 비례하여 줄어듭니다. 빠른 에이전트는 느린 에이전트보다 더 많은 작업과 더 많은 배치를 받습니다. 이것은 유용한 계산 시간이 테스트를 준비하고 결과를 보내는 시간과 비슷한 빠른 계산 문제에 특히 큰 효과를 줍니다.

에이전트 서비스 최적화 작업은 아직 끝나지 않았습니다. MQL5 Cloud Network에서 원격 에이전트의 효율적인 운영을 위해서는 통신 제공 비용을 줄이는 것이 주요 문제입니다.

 

이해를 도와주세요!

다음 코드 블록은 데모 계정의 터미널에서 제대로 작동하지만 테스트할 때 오류 메시지 4109 가 표시 됩니다.

 if (! ChartGetDouble ( 0 , CHART_PRICE_MAX , 0 ,price_max))
 {
   printf ( __FUNCTION__ , ": Не получены данные по максимальной цене. Ошибка: %g." , GetLastError ());
 }

와 같은 상황이 발생합니다

 if (! ChartGetDouble ( 0 , CHART_PRICE_MIN , 0 ,price_min))
 {
   printf ( __FUNCTION__ , ": Не получены данные по минимальной цене. Ошибка: %g." , GetLastError ());
 }
 
slyusar :

이해하도록 도와주세요!

다음 코드 블록은 데모 계정의 터미널에서 제대로 작동하지만 테스트하면 오류 메시지 4109 가 표시 됩니다.

와 같은 상황이 발생합니다

테스트하는 동안 차트와 그래픽 개체는 모델링되지 않습니다. 이는 테스트 속도를 급격하게 감소시키기 때문입니다.
 
Renat :
테스트하는 동안 차트와 그래픽 개체는 시뮬레이션되지 않습니다. 이는 테스트 속도를 급격하게 감소시키기 때문입니다.
이해합니다. 감사합니다. 이 상황에서 벗어날 방법이 있습니까?
 
Renat :
테스트하는 동안 차트와 그래픽 개체는 모델링되지 않습니다. 이는 테스트 속도를 급격하게 감소시키기 때문입니다.
그래픽이 없는 그런 시뮬레이션이 "시각화"가 없는 모드에만 있기를 정말 바랍니다.
 
sergeev :
그래픽이 없는 그런 시뮬레이션이 "시각화"가 없는 모드에만 있기를 정말 바랍니다.
나는 완전히 지원합니다. 그래픽은 때때로 매우 필요합니다 ...
 
Renat :

거래 전략 테스터를 최적화하는 이전 작업 으로 돌아갑니다.

425 빌드에 대한 전체 계획의 개선 사항은 다음과 같습니다.

  • 패스 준비를 위한 시스템 오버헤드 감소
  • 설정을 단순화한 시뮬레이션 유형 선택에 명시적 모드 "수학 계산" 추가

다음은 빌드 425에서 동일한 하드웨어(4개의 로컬 에이전트) 및 깨끗한 캐시에 대한 결과입니다.

원래 제기된 질문 (오버헤드는 패스당 2초)과 비교하여 문제를 성공적으로 해결했습니다. 25초 대신 동일한 작업을 7초로 간주했습니다.

태스크 번들링은 시스템 오버헤드를 방지하기 위한 기초가 되었습니다. 이제 각 에이전트에 대해 처리 속도가 측정되고 계산을 위해 1에서 64까지의 작업 팩이 발행됩니다. 결과적으로 테스트를 준비하고 결과를 얻는 데 걸리는 시간이 그에 비례하여 줄어듭니다. 빠른 에이전트는 느린 에이전트보다 더 많은 작업과 더 많은 배치를 받습니다. 이것은 유용한 계산 시간이 테스트를 준비하고 결과를 보내는 시간과 비슷한 빠른 계산 문제에 특히 큰 효과를 줍니다.

에이전트 서비스 최적화 작업은 아직 끝나지 않았습니다. MQL5 Cloud Network에서 원격 에이전트의 효율적인 운영을 위해서는 통신 제공 비용을 줄이는 것이 주요 문제입니다.

개선을 위한 매우 심각한 변경 - 감사합니다.

64개 매개변수 제한은 어떻습니까? 이것은 적어도 나에게 옵티마이저의 전체 사용을 방해하는 유일한 요소입니다. 그리고 모든 종류의 문제를 잊고 "실제"로 즉시 작성하여 코드 변경 없이 테스터에서 최적화할 수 있는 방법.

 
테스트 시각화 도우미를 시작한 후 매개변수를 처리합니다.
 
joo :

개선을 위한 매우 심각한 변경 - 감사합니다.

64개 매개변수 제한은 어떻습니까? 이것은 적어도 나에게 옵티마이저의 전체 사용을 방해하는 유일한 요소입니다. 그리고 모든 종류의 문제를 잊고 "실제"로 즉시 작성하여 코드 변경 없이 테스터에서 최적화할 수 있는 방법.

나는 지원한다.
레나트 :
테스트 시각화 도우미를 시작한 후 매개변수를 처리합니다.
고맙습니다! 기다릴 것이다.
 
Renat :

거래 전략 테스터를 최적화하는 이전 작업 으로 돌아갑니다.

다음은 빌드 425에서 동일한 하드웨어(4개의 로컬 에이전트) 및 깨끗한 캐시에 대한 결과입니다.

원래 제기된 질문 (오버헤드는 패스당 2초)과 비교하여 문제를 성공적으로 해결했습니다. 25초 대신 동일한 작업을 7초로 간주했습니다.

출시를 준비 중인 다음 빌드에서는 수학 문제의 대량 계산을 최적화하기 위해 많은 작업을 수행했습니다. 시스템 오버헤드가 0으로 감소했습니다.

이제 동일한 하드웨어(Intel Q9400, 4개의 로컬 코어)에서 동일한 작업이 1초가 소요되는 데 ~18,000개의 작업이 필요합니다(마지막에는 7초, 그 전에는 25초).

2011.04.04 20:12:34    Tester    optimization passed in 0 minutes 01 seconds
2011.04.04 20:12:34    Tester    genetic optimization finished on pass 18432 (of 1000000002000000001)
2011.04.04 20:12:34    Tester    result cache was used 9718 times
2011.04.04 20:12:34    Tester    genetics is over


비교를 위해 동일한 수학적 문제가 400만 패스를 렌더링하는 데 동일한 하드웨어에서 얼마나 많은 시간을 소비하는지 보여줄 수 있습니다.



2011.04.04 20:10:34    Tester    optimization passed in 0 minutes 46 seconds
2011.04.04 20:10:34    Tester    optimization finished, total passes 4004001


46초 안에 400만 개의 작업이 완전히 계산되고 결과가 있는 400만 개의 행이 모두 최적화 결과 창에 표시되고 전체 테이블이 임의의 필드로 즉시 정렬되며 최적화 그래프는 400만 개의 값을 모두 빠르게 그리고 3D 그래프는 동일한 결과에서 3차원 표면을 만들고 다른 각도로 비틀기: