Ottimizzazione degli algoritmi. - pagina 6

 
C-4:

Tutto il problema è nel secondo ciclo. Gestisce simultaneamente i rami destro e sinistro da un potenziale estremo e quindi passa solo attraverso (N - 1)/2 barre, ma non è sufficiente. Le misurazioni mostrano che il tempo impiegato per cercare un estremo in una progressione aritmetica dipende dal periodo N, il che è molto, molto brutto:

Manca almeno una pausa:

//Перебираем все бары
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; // А зачем искать дальше?
   }
}

Meglio ancora, dividere davvero la parte superiore e inferiore, e fermarsi immediatamente dopo un controllo infruttuoso.

 
Mathemat:

Se tutto il resto fallisce, provate OCL.

Non farà molta differenza.
 
TheXpert:
Non farà una grande differenza.
Sì, lo farà. Questo perché il compito non richiede un'esecuzione sequenziale. L'intera storia delle barre può essere divisa in k segmenti, ognuno dei quali sarà elaborato da un diverso core della CPU. Non conosco la meccanica di OCL, ma penso che il principio sia lo stesso qui. Lo stesso zig-zag è un'altra questione - è sequenziale, ogni nuova linea inizia dalla fine della precedente, quindi dividerlo in sottocompiti è estremamente difficile o addirittura impossibile.
 
komposter:

Manca almeno una pausa:

Meglio ancora, separare davvero la parte superiore e inferiore, e fermarsi immediatamente dopo un controllo infruttuoso.

Di nuovo, separando la parte superiore e inferiore si ottengono due passaggi per. Il che raddoppia il tempo di ricerca. La separazione da sola non dà alcun guadagno di prestazioni senza usare il multithreading, specialmente per piccoli n.
 

Tuttavia, OCL (o il parallelismo in senso generale) non è un'ottimizzazione algoritmica, ma piuttosto tecnica.

Dubito che nel vostro caso ci sia la necessità di parallelizzare la soluzione O(N)-variante più veloce al problema.

 
C-4:
Lo farà.

No yada yada? Mostrami.

Quindi, buona fortuna. Discutere l'ottimizzazione di un algoritmo con una complessità che dipende linearmente dal valore di un parametro è probabilmente qualcosa che non avete da fare.

 
TheXpert:

No yada yada? Mostrami.

Comunque, buona fortuna. Discutere l'ottimizzazione di un algoritmo con complessità linearmente dipendente dal valore di un parametro - non avete davvero nulla da fare.

OK, finirò di completare l'algoritmo e posterò i risultati del parallelismo nello studio.

hrenfx:

Tuttavia, OCL (o il parallelismo in senso generale) non è un'ottimizzazione algoritmica - è più un'ottimizzazione tecnica.

Dubito che ci sia bisogno di parallelizzare la soluzione O(N)-variante più veloce nel vostro caso.

Come posso dire. Qualsiasi parallelizzazione è sempre una seria complicazione degli algoritmi. Inoltre, se non si parallelizza un algoritmo con dipendenza lineare dalla quantità di dati, cos'altro si può parallelizzare?

In breve, riscriverò l'algoritmo e vedrò cosa porta.

 
C-4:
Anche in questo caso, la separazione di top e bottom si traduce in due passaggi per. Questo raddoppia il tempo di ricerca. La separazione da sola non dà un guadagno di prestazioni senza usare il multithreading, specialmente per piccoli n.

Come può essere così sicuro?

Il mio controllo dimostra il contrario:

01:29:25 SpeedTest EURUSD,M15 ingressi: Interazioni=10000; pperiod=10;

01:29:25 SpeedTest EURUSD,M15: Numero di barre = 3780

01:30:46 SpeedTest EURUSD,M15: Funzione originale: 81.558 sec, extrema: 131 / 121

01:31:10 SpeedTest EURUSD,M15: Con la mia modifica (pausa): 23.291 sec, extrema: 131 / 121

01:31:27 SpeedTest EURUSD,M15: Con la mia pausa (break): 17.565 sec, extrema: 131 / 121

In allegato c'è uno script mq4.

File:
SpeedTest.mq4  4 kb
 

Un altro test per completare il quadro:

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

01:38:56 SpeedTest EURUSD,M1: Numero di barre = 33896

01:50:19 SpeedTest EURUSD,M1: Funzione originale: 683.565 sec, extrema: 121 / 127

01:50:54 SpeedTest EURUSD,M1: Con la mia modifica (rottura): 34.383 sec, extrema: 121 / 127

01:51:16 SpeedTest EURUSD,M1: Con la mia pausa (break): 22.714 sec, extrema: 121 / 127

 
komposter:
C.T.D. ha scritto esattamente questo nel suo primo post.