Ticaret fırsatlarını kaçırıyorsunuz:
- Ücretsiz ticaret uygulamaları
- İşlem kopyalama için 8.000'den fazla sinyal
- Finansal piyasaları keşfetmek için ekonomik haberler
Kayıt
Giriş yap
Gizlilik ve Veri Koruma Politikasını ve MQL5.com Kullanım Şartlarını kabul edersiniz
Hesabınız yoksa, lütfen kaydolun
...
Gerçek hayatta tek bir çekirdeğin gücünden yoksun böyle bir danışmanı hayal etmek bile zor. Örneğin, Uzman Danışman test cihazında günde bir sembolün yıllık geçmişini bir kez geçerse (bu çok fazla! Muhtemelen kodun yeniden yazılması gerekiyor!), o zaman gerçek hayatta işlemciyi şu kadar yükleyecektir: ortalama 1/250 güç = %0.4
On sembolle ilgili bir danışman için ortalama yük %4'tür. Diğer kernelleri yüklemenin pek bir anlamı yok.
Konstantin ( Lizar ) fikrine gelince, bence fena değil. Ancak bu tür kararlar için, doğrudan grafikten gelen olayları ve özel olarak oluşturulan olayları ayırmaktan zarar gelmez. Onlar. iki olay kuyruğuna ve buna bağlı olarak iki işleyiciye sahip olmak güzel olurdu (özel olaylar için OnUserEvents gibi bir şey).
Ayrıca, özel olaylara ilginç bir ekleme, önceliklerini açıkça belirtme yeteneği olacaktır (0'dan 9'a kadar), bu da kullanıcının belirli olayların önceden alınmasını ve işlenmesini kontrol etmesine izin verebilir. Örneğin, böyle bir fırsat, daha düşük bir değere sahip olayları yürütmeye ve daha büyük bir kuyruktan kaldırmaya izin verir (kuyruk daha önemli olaylarla doluysa, yenileri sıraya alınmaz).
Hiç yazılım geliştirme yapmadım, bu yüzden yazılım geliştiricilerin teknik dilini konuşamam. 4 çekirdekli bilgisayarımdan ve MT5'ten ne almak istediğimi anlatacağım. Genel olarak, şöyle görünür:
1. Birkaç aracı işlemek şu anda bile mümkündür ve burada geliştiriciler tamamen uygulanabilir bir çözüm yaratmışlardır.
2. Test cihazının çalışması ve bir grup çekirdek pahasına. Bu özel bir durumdur ve bu mekanizmayı gerçek ticaretle karşılaştırmak temelde doğru değildir. Sorunu test cihazıyla çözmenin özü, bir uzman için birkaç seçeneğe (veya daha doğrusu bir uzman + bir dizi benzersiz parametre kümesine) sahip olmanın, hesaplamaları mevcut tüm çekirdeklere / aracılara dağıtmanın oldukça mantıklı olmasıdır. Böylece, tüm görev kümesi için eşzamansız hale geliriz, ancak tek bir aracının bakış açısından her şey senkronize edilir.
3. Çoklu kullanım söz konusu olduğunda, aynı anda birkaç sembolü işlemekle ilgili değil, aynı anda birkaç olayı işlemekle ilgilidir (ve belirli bir bireysel Uzman Danışman çerçevesinde). Terminalin birden fazla versiyonunda ne yoktu.
Geliştiriciler de anlaşılabilir: genel giderler çok yüksek, kullanıcıların bileşimi çok "çeşitli", veri senkronizasyonunda "çok iş parçacıklı" bir Uzman Danışmanın erişebileceği çok fazla sorun var, vb.
Öte yandan, olaylarla ilgili fikir mantıksal sonuna getirilmez. Peki, "çoklu iş parçacığı" uygulamak pahalı ve sorunludur, ancak terminalin kendi içinde süreçleri ve bilgi akışlarını mümkün olduğunca paralel hale getirebilirsiniz + maksimum sayıda görevi (ve normal bir parametre kümesiyle) çözmeye yetecek bir dizi işleyici oluşturun ).
01/04/2010 - 09/01/2011 dönemi için M5'te 12 para biriminde Uzman Danışmanım 1436 saniyede (24 dakika) tek geçiş yapmakta ve aynı zamanda 5687 işlem yapmaktadır. Bu durumda sadece bir çekirdek yüklenir ve diğer üçü boşta kalır. Yani her geçişte platformun bilgisayarın gücünü kullanmamasından dolayı zamanın 3/4'ünü kaybediyorum. Bir stratejide hata ayıklarken bu, platformun önemli bir dezavantajıdır. Çekirdekler tamamen yalnızca optimizasyon için kullanılır. Ancak optimizasyon, tek çalıştırmalardan çok daha nadirdir. Ve tek seferde çok fazla zaman kaybedilir.
"Zamanın 3/4'ünü kaybetti" yaklaşımı, ne düşündüğünüzü gösterir: çoklu iş parçacığı kullanımı, birdenbire kaçırılan bir fırsattır ve geliştiricinin net bir şekilde gözden kaçırılmasıdır.
Ne yazık ki, sıralı görevlerde çoklu kullanım (ve test cihazının tek geçişi sıralı bir görevdir) ücretsiz değildir. Gerçekte, çoklu kullanım, süreç senkronizasyonu için çok büyük (bazen birden fazla) kayıplara sahiptir. Aslında, paylaşılan kaynaklara tüm erişimlerin senkronizörlerle bağlanması gerekir.
Test cihazının test süresinin neredeyse %99'unda herhangi bir engelleme olmadan tek bir iş parçacığında çalışmasını sağlamak için test cihazını kasıtlı olarak terminalden ayrı bir işleme taşıdık. Bu, hızda önemli bir artış sağladı.
"Her uzmana çoklu görev uygulayalım" cümlesi, bu durumda çoklu kullanım maliyetinin (toplam yavaşlama) ve sonuçlarının (profesyonel olmayan geliştiricilerin %99'u için yavaşlama + çatının yıkılması) tamamen yanlış anlaşılmasından kaynaklanmaktadır.
Terminalde ve test cihazında çoklu görev kullanma sorunlarını etkin bir şekilde çözdük ve uzak aracı ve MQL5 Cloud Network modlarında neredeyse sınırsız güç ölçeklendirme modunu etkinleştirdik.
Farklı sembollere sahip 12 farklı çizelge varsa, o zaman her bir çizelgenin sembolü, diğerlerini etkilemeden açıkça kendi akışında çalışır.
Grafikler yavaşlamaya başlarsa, bunun nedeni banaldır - göstergelerden biri çok ekonomik değildir. Bu durumda, çoklu görev yardımcı olmaz, çünkü kök, alnına göstergeler yazan, verimliliği önemsemeyen bir programcının çalışmasının sonuçlarındadır.
Ters grafiği alamıyorum, bir şey anlamıyorum, bu seçenekte yeni çubuk hatalı
Baktığım orijinal göstergeyi ekliyorum
bana sorunun ne olduğunu söyle
çoklu para birimi yaz
MA gösterge tutamağını al
Aynısını şampiyonada izin verilen diğer 10 para birimi için yapıyorum, ancak test ederken hemen 4801 hatası veriyor, 12 para biriminin tümü geçmişte (bir çeşit)
Testi EURUSD grafiğinde çalıştırıyorum
danışman GBPUSD çiftini test ediyor (en iyi duruma getirmek için ayarlarda ayarladım)
bana sorunun ne olduğunu söyle
çoklu para birimi yaz
MA gösterge tutamağını al
Aynısını şampiyonada izin verilen diğer 10 para birimi için yapıyorum, ancak test ederken hemen 4801 hatası veriyor, 12 para biriminin tümü geçmişte (bir çeşit)
Testi EURUSD grafiğinde çalıştırıyorum
danışman GBPUSD çiftini test ediyor (en iyi duruma getirmek için ayarlarda ayarladım)
papaklass :
Şimdi bana bu basit soruyu cevapla...
Kibarca olmasa da daha basit cevap vereceğim.
Ne yazık ki, kesinlikle temassızsınız ve süreçler hakkında yalnızca yüzeysel fikirler gösteren açıklamalar yapıyorsunuz.
Korkarım ki, teknik argümanlarımızın çoğu anlaşılmayacak, tıpkı temel senkronizasyon sorunu ve onun sağlanmasındaki kayıp bile anlaşılmadığı gibi.
Not: talepte bulunmanıza gerek yok "ve bize argümanları anlatın, biz de akıl yürütelim", durum kesinlikle açık
Acemiye söyle ve şu soruların cevaplarını bulamadın:
1) Bir sonraki öğeyi dinamik bir diziye eklerken, ArrayResize kullanılarak genişletilmesi gerekiyor mu?
2) MQL5'te dinamik dizi i'den bir öğeyi kaldırmak için bir işlev var mı (biri - örneğin, dizinin ortasında) ? Değilse, dili kullanarak bunu yapmanın en iyi yolu nedir?
Acemiye söyle ve şu soruların cevaplarını bulamadın:
1) Bir sonraki öğeyi dinamik bir diziye eklerken, ArrayResize kullanılarak genişletilmesi gerekiyor mu?