알고리즘 최적화. - 페이지 6

새 코멘트
 
C-4 :

전체 문제는 두 번째 주기에 있습니다. 잠재적 극값에서 왼쪽 및 오른쪽 분기를 동시에 처리하므로 (N - 1)/2개의 막대만 반복하지만 이것으로는 충분하지 않습니다. 측정값은 산술 진행에서 극한값을 찾는 데 소요된 시간이 기간 N에 따라 달라지는 것을 보여줍니다. 이는 매우 매우 나쁩니다.

하나 이상의 휴식 시간이 누락되었습니다.

 //Перебираем все бары
for ( int bar = 0 ; bar < MyQuotes.Count; bar++)
{
   //Подготовка данных
   ...
   int pperiod = (N - 1 )/ 2 ;
   //Перебираем бары относительно потенциального экстремума
   for ( int i = 1 ; i <= pperiod; i++)
   {
       if (MyQuotes.High[bar - i] > MyQuotes.High[bar] ||
         MyQuotes.High[bar + i] > MyQuotes.High[bar])
         up = false ;
       if (MyQuotes.Low[bar - i] < MyQuotes.Low[bar] ||
         MyQuotes.Low[bar + i] < MyQuotes.Low[bar])
         down = false ;

       if ( !up && !down ) break ; // А зачем искать дальше?
   }
}

정말 위아래로 분리해서 체크가 안되면 바로 멈추는게 좋습니다.

 
Mathemat :

다른 모든 방법이 실패하면 OCL을 시도하십시오.

그것은 당신에게 큰 승리를주지 않을 것입니다.
 
TheXpert :
그것은 당신에게 큰 승리를주지 않을 것입니다.
그것은 또 어떻게 줄 것입니다. 그리고 모든 작업은 순차적 실행이 필요하지 않기 때문입니다. 막대의 전체 기록은 k개의 세그먼트로 나눌 수 있으며 각 세그먼트는 자체 CPU 코어를 처리합니다. OCL의 메카니즘은 잘 모르지만 여기에서도 같은 원리라고 생각합니다. 지그재그 자체는 또 다른 문제입니다. 일관성이 있고, 각각의 새 줄은 이전 줄의 끝에서 시작하므로 하위 작업으로 나누는 것이 극히 어렵거나 불가능합니다.
 
komposter :

하나 이상의 휴식 시간이 누락되었습니다.

정말 위아래로 분리해서 체크가 안되면 바로 멈추는게 좋습니다.

다시, 상단과 하단을 분리하면 두 개의 패스가 생성됩니다. 검색 시간이 두 배로 늘어납니다. 멀티스레딩을 사용하지 않는 나눗셈 자체는 특히 작은 n의 경우 성능 향상을 제공하지 않습니다.
 

그러나 OCL(또는 일반적인 의미의 병렬화)은 알고리즘 최적화가 아니라 기술 최적화입니다.

귀하의 경우 문제에 대한 가장 빠른 O(N) 솔루션을 병렬화할 필요가 있는지 의심됩니다.

 
C-4 :
그것은 또 어떻게 줄 것입니다.

그리고 라라 없이? 보여주다.

한마디로 행운을 빕니다. 매개변수의 값에 선형적으로 의존하는 복잡성을 가진 알고리즘의 최적화를 논의하는 것은 분명히 할 일이 아닙니다.

 
TheXpert :

그리고 라라 없이? 보여주다.

한마디로 행운을 빕니다. 매개변수 값에 선형적으로 의존하는 복잡성을 가진 알고리즘의 최적화를 논의하는 것은 분명히 할 일이 아닙니다.

확인. 알고리즘을 끝내고 병렬화 결과를 스튜디오에 게시하겠습니다.

hrenfx :

그러나 OCL(또는 일반적인 의미의 병렬화)은 알고리즘 최적화가 아니라 기술 최적화입니다.

귀하의 경우 문제에 대한 가장 빠른 O(N) 솔루션을 병렬화할 필요가 있는지 의심됩니다.

말하는 방법. 모든 병렬화는 항상 알고리즘의 심각한 복잡성입니다. 또한 데이터 양에 대한 선형 종속성을 사용하여 알고리즘을 병렬화하지 않는 경우 병렬화하는 것이 의미가 있습니까?

요컨대, 나는 알고리즘을 다시 작성하고 그것이 무엇을 줄지 볼 것입니다.

 
C-4 :
다시, 상단과 하단을 분리하면 두 개의 패스가 생성됩니다. 검색 시간이 두 배로 늘어납니다. 멀티스레딩을 사용하지 않는 나눗셈 자체는 특히 작은 n의 경우 성능 향상을 제공하지 않습니다.

그런 자신감이 어디 있습니까?

내 수표는 반대를 보여줍니다.

01:29:25 SpeedTest EURUSD,M15 입력: 상호 작용 = 10000 ; pperiod= 10 ;

01:29:25 SpeedTest EURUSD,M15: 막대 수 = 3780

01:30:46 SpeedTest EURUSD,M15: 원래 기능: 81.558 초, 극한값: 131 / 121

01:31:10 SpeedTest EURUSD,M15: 내 편집 포함(중단): 23.291 초, 극한값: 131 / 121

01:31:27 SpeedTest EURUSD,M15: 주기: 17.565 초, 극한: 131 / 121

첨부 파일의 mq4 스크립트.

파일:
SpeedTest.mq4  4 kb
 

그림을 완성하려면 한 번 더 테스트하십시오.

01:38:56 SpeedTest EURUSD,M1 입력: Interations= 1000 ; pperiod= 100 ;

01:38:56 SpeedTest EURUSD,M1: 막대 수 = 33896

01:50:19 SpeedTest EURUSD,M1: 원래 기능: 683.565 초, 극한값: 121 / 127

01:50:54 SpeedTest EURUSD,M1: 내 편집 포함(중단): 34.383 초, 극한값: 121 / 127

01:51:16 SpeedTest EURUSD,M1: 주기: 22.714 초, 극한: 121 / 127

 
komposter :
씨티디 제가 첫 포스팅에 썼던 바로 그 내용입니다.
12345678910
새 코멘트