Özel bir gösterge kullanırken Uzman Danışmanı hızlandırma teorisi (işlev - iCustom)

 

Programcı olmadığımı ve yanılıyor olabileceğimi söyleyerek başlayacağım, ancak aşağıda önerilen fikir hakkında hesaplamalara dayalı profesyonellerin görüşlerini duymak isterim.

Uzman Danışmanı birkaç aşamada geliştirirken özel göstergelerin kullanılması acil bir iştir. Bu, özellikle programcılar birbirini değiştirdiğinde geçerlidir ve daha sonra danışmanın mantığının bir kısmını bir göstergeye dikmek daha iyidir - mantığı çalıştırın (hesaplamaları ve alaka düzeyini kontrol edin) ve ardından fikrin yeni bir parçası üzerinde çalışın. Sonuç olarak, aslında göstergeden bilgi talep eden ve beklenen ve gerçek verileri karşılaştırarak karar veren çok karmaşık olmayan bir Uzman Danışman elde edilir.

Bununla birlikte, bu yaklaşımın önemli bir dezavantajı vardır - böyle bir Uzman Danışmanın hızı. Gerçek şu ki, özel göstergelerden ne kadar sık veri istenirse, hesaplama o kadar yavaş olur ve optimizasyon için o kadar fazla kaynak (bellek) gerekir.

MT4'te çalışırken, anladığım kadarıyla prensip bu problem için aynı.

Ve sorun, iCustom göstergesinin kendisinin hesaplama hızında değil, Uzman Danışman ile olan bağlantısındadır.

Göstergenin 5 grafik arabelleği kullandığını ve EA'nın bu arabelleklerden bilgiye ihtiyacı olduğunu varsayalım, o zaman EA kodunda 5 iCustom işlevi kullanılmalıdır ve aslında, bir gösterge yerine, 5 kat daha fazla gerektiren grafiğe 5 gösterge koyun. kaynaklar. Belki de yanılıyorum ve derleyici bu durumu analiz ediyor - tek bir gösterge üzerinde bir hesaplama yapıyor ve talep edilen arabelleklerde tüm işlevlere aynı anda veri veriyor!? O zaman daha da fazla uydurmalarım boş.

Ancak, durum böyle değilse, neden göstergeden gelen bilgileri tek bir pekmezde birleştirmiyorsunuz?

Expert Advisor'ın performansını ölçerek bu konuda bir deney yapmayı öneriyorum.

Bunu yapmak için, 1'den büyük bir arabelleğe sahip özel bir gösterge almanız ve ek bir arabellek eklemeniz gerekir.

Algoritma mantıklıdır (matematiksel olmadan):

1. Tamponların değerini indikatörde tamsayılara çevirelim, sayı başına basamaklara bağlı olarak toplamda 3 tampon var, şuydu: 1.21101; 1.13; 5 oldu: 121101;113;5

2. İlk sayıdan sonra kaç basamak yerleştirilmesi gerektiğini düşünüyoruz - bizim durumumuzda 4, sonraki sayıdaki bir sonraki sayı 1'dir, bu değerler çarpanın gücüdür:

1.21101*10^4=1211010000

1.13*10^1=113

5*10^0=5 (0 olup olmadığını kontrol eder)

3. Sayıları toplayın ve 1211011135'i elde edin

4. Değeri tampon 4'e yazın

5. Expert Advisor 4'te gösterge tamponunu talep ediyoruz ve değeri ters sırada bileşenlere ayırıyoruz - daha sonra Expert Advisor için kullanılabilecek 3 rakam elde ediyoruz.

Birisi bu yaklaşımın hızını karşılaştırabilir mi, içinde mantıklı bir tane var mı?

 
...Допустим, индикатор использует 5 графических буферов и для работы советника требуется информация с этих буферов, тогда в коде советника необходимо использовать 5 функций iCustom, и фактически вместо одного индикатора наносить на график 5 индикаторов, что требует в 5 раз больше ресурсов. Быть может я не прав и компилятор анализирует это обстоятельство - делая расчет по одному индикатору и дает сразу всем функциям данные по востребованным буферам!? Тогда дальше мои измышления пусты...

Derleyici çok şey yapabilir ve yapabilir, ancak bunu değil :-)

...Ancak, bu yaklaşımın önemli bir dezavantajı var - böyle bir Uzman Danışmanın hızı. Gerçek şu ki, özel göstergelerden ne kadar sık veri istenirse, hesaplama o kadar yavaş olur ve optimizasyon için o kadar fazla kaynak (bellek) gerekir...

Ve bu optimize edilebilir. İlk olarak, göstergenin kendisi akıllıca yazılmalıdır (her bir işaret üzerindeki tüm çubukları yeniden hesaplamamak için) ve ikincisi, danışmanın çalışmasını bir şekilde yavaşlatmak için göstergenin çok ağır olması gerekir... kısacası...

Ve işte konuyla ilgili ilginç bir makale: " Yardımcı göstergeler için bellek tüketimini azaltma."

8 tf için 28 enstrüman için gösterge okumaları alan çok para birimli bir danışmanım vardı.

Bu 28*8=224 gösterge kopyası... Süreci nasıl optimize edeceğim konusunda çok uğraştım. ama oldukça kolay karar verdim - sadece "Grafikler" sekmesindeki "Penceredeki maksimum çubuklar" alanı için terminal ayarlarında küçük bir değer belirledim ... olarak hatırladığım kadarıyla bu alan için minimum 5 bin bar...

Уменьшаем расход памяти на вспомогательные индикаторы
Уменьшаем расход памяти на вспомогательные индикаторы
  • 2011.03.18
  • Andrew
  • www.mql5.com
Если индикатор для своих расчетов задействует значения множества других индикаторов, то такая система расходует много памяти. В статье рассмотрены несколько способов снижения расхода памяти при использовании вспомогательных индикаторов. Сэкономленная память позволит вам увеличить число одновременно используемых в терминале валютных пар, индикаторов и стратегий, что повысит надежность вашего торгового портфеля. Вот так простая забота о технических ресурсах вашего компьютера способна превратиться в материальные ресурсы на вашем депозите.
 

Özel göstergelerin sağladığı avantajlarla karşılaştırıldığında tamamen önemsiz olan test süresinde 1.2 - 1.3 kat artış olan ölçümler yaptım.

Yaklaşık 5 arabellek, çıktı yanlış. Parametreler aynıysa, yalnızca bir gösterge yüklenecektir.

 

Integer :

Yaklaşık 5 arabellek, çıktı yanlış. Parametreler aynıysa, yalnızca bir gösterge yüklenecektir.

Evet katılıyorum.

Farklı argümanlarla (arabellek numarası) CopyBuffer() işlevine 5 çağrı yapılacaktır . Ve göstergenin yalnızca bir kopyası olacak - tutamaç.

Yazar yüksek sesle "İvme Teorisi ..." konusunu aradı, ancak temel şeylerde - ayağıyla dişte değil.

-Aleks-, indikatör konusunda bir sürü makale var!


 
denkir :

Evet katılıyorum.

Farklı argümanlarla (arabellek numarası) CopyBuffer() işlevine 5 çağrı yapılacaktır . Ve göstergenin yalnızca bir kopyası olacak - tutamaç.

Yazar yüksek sesle "İvme Teorisi ..." konusunu aradı, ancak temel şeylerde - ayağıyla dişte değil.

-Aleks-, indikatör konusunda bir sürü makale var!


Yerleşik hindileri ve analoglarını iCustom aracılığıyla arama hızını bir şekilde ölçmeye çalıştım. Yaklaşık %20-50 daha hızlı yerleşik. Büyük olasılıkla, MQL'de değil, C++ ile yazılmış oldukları için.
 

denkir , danışmanın optimizasyon sürecindeki çalışmasından bahsediyorum, grafikteki mum sayısı oradaki hesaplama miktarını etkiler mi? Göstergelerin optimizasyonu ile ilgili makaleyi inceledim - seçeneklerin olduğunu biliyorum. Ancak bu durumda göstergenin ideal olduğunu düşünmek ve göstergeden Expert Advisor'a veri aktarma yöntemini araştırmak istiyorum. Programcı olmayan biri olarak gösterge kodunun optimalliğini kontrol etmek benim için zor - teknik şartnamede yazabileceğim maksimum değer 1 barlık bir gecikme ve hesaplama için bir geçmiş sınırıdır.

Integer :

Özel göstergelerin sağladığı avantajlarla karşılaştırıldığında tamamen önemsiz olan test süresinde 1.2 - 1.3 kat artış olan ölçümler yaptım.

Yaklaşık 5 arabellek, çıktı yanlış. Parametreler aynıysa, yalnızca bir gösterge yüklenecektir.

Hangi ölçümler alındı? Ve %30 benim için çok az değil.

Yaklaşık 5 tampon, sizi doğru anladıysam, o zaman göstergenin aynı giriş parametreleriyle, ikincisi danışman tarafından birden çok kez çağrıldığında ve farklı tamponlardan bilgi alındığında sadece bir gösterge hesaplanır?

Öyleyse, özel göstergeleri birleştirmek danışmanın işini hızlandırmalı mı? Örneğin bir göstergede, bağımsız ayarlarla farklı göstergelerin mantığını koymak mümkündür, bunlardan herhangi birini çağırırken tüm tamponlardan bir kerede bilgi alınır ve aynı anda başka bir tampondan bilgi talep edilmesi durumunda kullanılır. parametreler?

Vdev :
Yerleşik hindileri ve analoglarını iCustom aracılığıyla arama hızını bir şekilde ölçmeye çalıştım. Yaklaşık %20-50 daha hızlı yerleşik. Büyük olasılıkla, MQL'de değil, C++ ile yazılmış oldukları için.   

Bu bir gerçektir.
 

GODZILLA'dan son derece ilginç makale " Ara hesaplamalar için ek tamponlar olmadan ortalama fiyat serileri " .

2010 yılında tekrar yazılmıştır.

Bölüm 3 var. Koddaki teknik ve özel göstergelere yapılan çağrılarla analogları ile sınıfları kullanarak ortaya çıkan göstergenin karşılaştırılması

Усреднение ценовых рядов без дополнительных буферов для промежуточных расчетов
Усреднение ценовых рядов без дополнительных буферов для промежуточных расчетов
  • 2010.10.25
  • Nikolay Kositsin
  • www.mql5.com
Статья о традиционных и не совсем традиционных алгоритмах усреднения, упакованных в максимально простые и достаточно однотипные классы. Они задумывались для универсального использования в практических разработках индикаторов. Надеюсь, что предложенные классы в определенных ситуациях могут оказаться достаточно актуальной альтернативой громоздким, в некотором смысле, вызовам пользовательских и технических индикаторов.
 
denkir :

Evet katılıyorum.

Farklı argümanlarla (arabellek numarası) CopyBuffer() işlevine 5 çağrı yapılacaktır . Ve göstergenin yalnızca bir kopyası olacak - tutamaç.

Yazar yüksek sesle "İvme Teorisi ..." konusunu aradı, ancak temel şeylerde - ayağıyla dişte değil.

-Aleks-, indikatör konusunda bir sürü makale var!


Yoksa kelimeleri sayılarla onaylayarak hipotezimi (dörtlü, tercihen) çürütebilir misiniz?

Teorimle ilgili konu - adı normal :)

 
-Aleks- :

denkir , danışmanın optimizasyon sürecindeki çalışmasından bahsediyorum, grafikteki mum sayısı oradaki hesaplama miktarını etkiler mi?

-Aleks- , Tester hakkında geliştiricilere sormak lazım...

Ama bana öyle geliyor ki, tartışırken terimlerde bir sorun var. Göstergeyle çalışmak için hesaplama hızını düşürmeniz veya RAM'den tasarruf etmeniz mi gerekiyor?



 
denkir :

-Aleks- , Tester hakkında geliştiricilere sormak lazım...

Ama bana öyle geliyor ki, tartışırken terimlerde bir sorun var. Göstergeyle çalışmak için hesaplama hızını düşürmeniz veya RAM'den tasarruf etmeniz mi gerekiyor?

Bana öyle geliyor ki benim yöntemim bu iki sorunu çözecek. Belki de ben hatalıyım.

Optimizasyon yaparken hız önemlidir ancak RAM'i doldurduktan sonra yine gözlemlerime göre bir geçişin işlem hızı düşüyor.

 
-Aleks- :

Birisi bu yaklaşımın hızını karşılaştırabilir mi, içinde mantıklı bir tane var mı?

Bu yaklaşım, göstergenin bellek tüketimini azaltacaktır (önceki ve sonraki arabellek sayısındaki farkın yaklaşık katı), ancak işlemci üzerindeki yükü artıracaktır (hem "birleştirme" hem de "çözümleme" sürekli yapılmalıdır).

Ve gösterge 5-arabellek ise, ilk iCustom araması tüm arabellekleri hesaplayacaktır, sonraki aramalar ve diğer arabelleklere yönelik istekler yalnızca hazır bilgileri okuyacaktır (hesaplama için yeni verilerin görünümüne kadar).

Gerçekten ağır bir göstergeniz varsa, kendi önbellek sisteminizi oluşturun, böylece ilk çalıştırmada veriler hesaplanır ve dosyaya yazılır ve sonraki çalıştırmalarda sadece okunur. Bunu yaptım, çok daha hızlı çıkıyor.

Ancak vakaların% 95'inde tüm bunlar gerekli değildir, test cihazı zaten yeterince hızlıdır ve 5-ke'de bulutu da bağlayabilirsiniz.

İyi şanlar!