Algoritmaların optimizasyonu. - sayfa 6

Yeni yorum
 
C-4 :

Bütün sorun ikinci devrede. Potansiyel ekstremumdan sol ve sağ dalları eşzamanlı olarak işler ve bu nedenle yalnızca (N - 1)/2 çubuk üzerinde yinelenir, ancak bu yeterli değildir. Ölçümler, aritmetik bir ilerlemede bir ekstremum aramak için harcanan zamanın, çok, çok kötü olan N periyoduna bağlı olduğunu gösteriyor:

En az bir ara eksik:

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

Üst ve alt kısımları gerçekten ayırmak ve başarısız bir kontrolden hemen sonra durmak daha iyidir.

 
Mathemat :

Her şey başarısız olursa, OCL'yi deneyin.

Size büyük bir kazanç sağlamayacaktır.
 
TheXpert :
Size büyük bir kazanç sağlamayacaktır.
Başka nasıl verecek. Ve hepsi, görev sıralı yürütme gerektirmediği için. Çubukların tüm geçmişi, her biri kendi CPU çekirdeğini işleyecek olan k parçaya bölünebilir. OCL'nin mekaniğini bilmiyorum ama sanırım burada da aynı prensip var. Zigzagın kendisi başka bir konudur - tutarlıdır, her yeni satır bir öncekinin sonundan başlar, bu da alt görevlere ayırmanın son derece zor, hatta imkansız olduğu anlamına gelir.
 
komposter :

En az bir ara eksik:

Üst ve alt kısımları gerçekten ayırmak ve başarısız bir kontrolden hemen sonra durmak daha iyidir.

Yine, üst ve alt ayırma, geçişler için ikiye neden olur. Bu da arama süresini ikiye katlar. Tek başına, çoklu kullanım kullanmadan bölme, özellikle küçük n için bir performans kazancı sağlamaz.
 

Yine de OCL (veya genel anlamda paralelleştirme) algoritmik bir optimizasyon değil, teknik bir optimizasyondur.

Sizin durumunuzda soruna en hızlı O(N) çözümünü paralelleştirmeye ihtiyaç olduğundan şüpheliyim.

 
C-4 :
Başka nasıl verecek.

Ve la-la olmadan? Göstermek.

Kısacası, iyi şanslar. Parametrenin değerine doğrusal olarak bağlı karmaşıklığa sahip bir algoritmanın optimizasyonunu tartışmak, görünüşe göre gerçekten yapılacak bir şey değil.

 
TheXpert :

Ve la-la olmadan? Göstermek.

Kısacası, iyi şanslar. Bir parametrenin değerine doğrusal olarak bağımlı karmaşıklığa sahip bir algoritmanın optimizasyonunu tartışmak, görünüşe göre gerçekten yapılacak bir şey değildir.

TAMAM. Algoritmayı bitirip paralelleştirmenin sonuçlarını stüdyoya göndereceğim.

hrenfx :

Yine de OCL (veya genel anlamda paralelleştirme) algoritmik bir optimizasyon değil, teknik bir optimizasyondur.

Sizin durumunuzda soruna en hızlı O(N) çözümünü paralelleştirmeye ihtiyaç olduğundan şüpheliyim.

Nasıl denir. Herhangi bir paralelleştirme her zaman algoritmaların ciddi bir komplikasyonudur. Ayrıca, veri miktarına doğrusal bağımlı bir algoritmayı paralelleştirmezseniz, o zaman paralelleştirmenin anlamı nedir?

Kısacası algoritmayı yeniden yazacağım bakalım ne verecek.

 
C-4 :
Yine, üst ve alt ayırma, geçişler için ikiye neden olur. Bu da arama süresini ikiye katlar. Tek başına, çoklu kullanım kullanmadan bölme, özellikle küçük n için bir performans kazancı sağlamaz.

Nerede böyle bir güven?

Çekim tam tersini gösteriyor:

01:29:25 SpeedTest EURUSD,M15 girişleri: Etkileşimler= 10000 ; periyot= 10 ;

01:29:25 SpeedTest EURUSD,M15: Çubuk sayısı = 3780

01:30:46 SpeedTest EURUSD,M15: Orijinal fonksiyon: 81.558 sn, ekstrem: 131 / 121

01:31:10 SpeedTest EURUSD,M15: Düzenlememle (ara): 23.291 sn, ekstremum: 131 / 121

01:31:27 SpeedTest EURUSD,M15: Döngüsel: 17.565 sn, uç noktalar: 131 / 121

mq4 betiği ekte.

Dosyalar:
SpeedTest.mq4  4 kb
 

Resmi tamamlamak için bir test daha:

01:38:56 SpeedTest EURUSD,M1 girişleri: Etkileşimler= 1000 ; periyot= 100 ;

01:38:56 SpeedTest EURUSD,M1: Çubuk sayısı = 33896

01:50:19 SpeedTest EURUSD,M1: Orijinal fonksiyon: 683.565 sn, uç noktalar: 121 / 127

01:50:54 SpeedTest EURUSD,M1: Düzenlememle (ara): 34.383 sn, ekstremum: 121 / 127

01:51:16 SpeedTest EURUSD,M1: Döngüsel: 22.714 sn, uç noktalar: 121 / 127

 
komposter :
C.T.D. İlk mesajımda aynen bunu yazdım.
12345678910
Yeni yorum