Hatalar, hatalar, sorular - sayfa 2285
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
Ah-huh, senin durumunda sadece "çevik" kavramı çok göreceli. Bir kullanıcının bir dizi çubuk talep etmesi bir şeydir - bir parça bellek ona basitçe kopyalanmıştır. Veya bazı belirli zaman serileri talep edildiğinde, yapının boyutuna eşit sabit bir adımla verilerin basit bir kopyalanması da vardır. Ve başka bir konu - her sayı üzerinde ek hesaplamalar ve dönüşümler.
Her ne kadar kişisel olarak, hafızayı boşa harcamamak için kısa bir tarih tercih ederim, çünkü. neyse, depolaması için kendi dizilerimi düzenliyorum. O yüzden biraz beklemeye razıyım. Ancak diğer kullanıcıların çoğu bunun için sizi parçalara ayırır)
ps İdeal olsa da, bellekte geçmişi saklama modunu seçmek için terminalde böyle bir seçeneğe sahip olmak güzel olurdu. Örneğin, sistemin RAM'i az, ancak işlemcisi hızlıysa, bu çok faydalı olacaktır.
İyi bak. SDD'mde okuma ve yazma hızını ölçtüm. 8 bayt (1 değer tipi double veya datetime veya long) yazma ve okuma süresinin ~ 48 ns olduğu ortaya çıktı. Ve hesaplamalarıma göre, paketlenmiş bir diziden 8 baytlık bilgi okuma süresi 1-2 ns'dir. Onlar. Bir yapı elemanına erişimde 1-2 ns kaybetmemize rağmen, diskten yazma ve okumada 48 * 0.8 = 38 ns kazanırız. Aynı zamanda RAM ve disk alanından da 5 kat tasarruf sağlıyoruz. HDD hakkında genellikle sessiz kalın.
İyi bak. SDD'mdeki okuma ve yazma hızını ölçtüm. 8 bayt (1 değer tipi double veya datetime veya long) yazma ve okuma süresinin ~ 48 ns olduğu ortaya çıktı. Ve hesaplamalarıma göre, paketlenmiş bir diziden 8 baytlık bilgi okuma süresi 1-2 ns'dir. Onlar. Bir yapı elemanına erişimde 1-2 ns kaybetmemize rağmen, diskten yazma ve okumada 48 * 0.8 = 38 ns kazanırız. Aynı zamanda RAM ve disk alanından da 5 kat tasarruf sağlıyoruz. HDD hakkında genellikle sessiz kalın.
Bununla tartışmıyorum. Özellikle bir diskten veri indirmek söz konusu olduğunda, kesinlikle haklısınız. 4 yıl önce, SSD'nin hala oldukça nadir olduğu ve kullanıcıların büyük çoğunluğunun yavaş HDD'lerde oturduğu bir dönemde Renat ile bu konuda bir anlaşmazlık yaşadık. Bu yüzden (örnek olarak SSD'mi kullanarak) onu sabit disk işlemlerinin sistemdeki en frenleyici bağlantı olduğuna ikna etmeye çalıştım ve ondan tüketilen bilgi miktarını en aza indirmeye çalışmanız gerekir, bunun tersi değil. Ama işlemciyi gereksiz işlerle doldurmaya gerek yok gibi argümanları vardı ve genel olarak burada hepiniz aptalsınız, hiçbir şey anlamıyorsunuz vb. Genel olarak, her şey her zamanki gibi)
Doğru, şu anda SSD'ler gözle görülür şekilde hızlandı.
Yazma ve okuma süresinin 8 bayt olduğu ortaya çıktı.
Ticaret, otomatik ticaret sistemleri ve ticaret stratejilerinin test edilmesi hakkında forum
Hatalar, hatalar, sorular
fxsaber , 2018.09.10 21:28
Önce Optimizasyon günlüğü
Tester optimization finished, total passes 714240 Statistics optimization done in 7 hours 31 minutes 06 seconds Statistics local 714240 tasks (100%), remote 0 tasks (0%), cloud 0 tasks (0%) Core 1 connection closed Core 2 connection closed Core 3 connection closed Core 4 connection closed Core 5 connection closed Core 6 connection closed Core 7 connection closed Core 8 connection closed Tester 714240 new records saved to cache file 'tester\cache\Test.FILTER_EURUSD.rann_RannForex.M1.20180226.20180909.40.2D734373DF0CAD251E2BD6535A4C6C84.opt'Bu 7.5 saat boyunca SSD'ye büyük bir sıklıkta erişim sağlandı. Her geçişte keneler okunduysa, 7,5 saat boyunca saniyede ortalama 26 kez olduğu ortaya çıkıyor. Bu nedenle böyle vahşi yanıp sönme - 700 binden fazla okuma.
tek çalıştırma günlüğü
~130K tik ve 60K çubukların kullanıldığı görülebilir (Test Cihazında "Tüm geçmiş" modu seçilidir). Onlar. Eh, çok az tarih.
Terminaldeki özel bir sembolün geçmişi, çok fazla tarihsel veri içerir
Onlar. sembolün tarihinde, Tester'ın kullandığından biraz daha fazlası.
Tehdit SSD'ye bakmak üzücü... Optimizasyon hızı ne kadar yüksek olabilir? İşletim sisteminin bu verileri önbelleğe almaması garip, çünkü sıkıştırılmamış biçimde 7M kenelerden daha az.
Verilerin SSD'den değil de bellekten okunması/yazılması için mklink üzerinden RAM diske Terminalin hangi klasörü yerleştirilmelidir? Optimizasyon sırasında nasıl bir ivme kazandıracağını, veri sağlamaya hazırım.
Evet, arşivdir. Doğru anladıysam, şimdi diskte ne var, bellekte ne var, keneler ve dakika çubukları paketlenmemiş biçimde saklanıyor, yani. bir çubuk ( MqlRates yapısı ) için 60 bayttır ve bir onay işareti ( MqlTick yapısı ) için 52 bayttır.
Korku! Bu konuda uzun süredir bir şeyler yapılması gerekiyor.
Sıkıştırılmış diziler için asıl sorunun dizinin her bir öğesine hızlı erişim organizasyonu olduğunu anlıyorum.
Ancak, yalnızca paketlenmemiş dizinin her 256'ncı öğesini depolasanız ve diğer öğelerde yalnızca paketlenmemiş olanlara artışlar depolasanız bile, o zaman gözle, dizinin boyutu 4-5 kat azalır ve her öğeye erişim süresi çok fazla artmaz (belki 1 -2 nanosaniye kadar), ancak diziyi diskten ve diskten kaydetmek ve okumak için zaman açısından büyük bir tasarruf sağlar.
"Her şey senden önce çalındı" (c)
Günün başında - tam bir kene. Ardından teklif verin ve/veya isteyin ve/veya tamamen son, varsa diğer her şey artımlardır. Onay başına ortalama 10 bayt.
Kenelere erişim kesinlikle sıralı olduğundan, dizinin her bir öğesine hızlı erişimi organize etmede herhangi bir sorun yoktur.
"Test\cache\*.opt" girişinin kaynağını göndermenizi rica ederiz. İçerik, biçimin çok basit olduğunu gösteriyor.
Optimizasyon sonuçları ile çalışmak çok gereklidir. Teşekkür ederim!
Bazı nedenlerden dolayı, işlem sayısı arttıkça Test Cihazının performansı düşer. Aynı zamanda, danışman adına ticaret geçmişine erişim gerçekleşmez.
Bu pozisyon yanlış gibi görünüyor.
Test Cihazı, "Tüm geçmiş" moduna karşılık gelen aralığı hatırlar. Özel sembole tarih ekliyorum, Terminali yeniden yüklüyorum ve "Tüm geçmiş"e karşılık gelen aralık değişmeden kalıyor.
Ayrıca, tüm geçmişi seçerseniz, tüm geçmişi manuel olarak ayarlarsanız, her şey yolunda demektir. Lütfen düzeltin.
Belirtilen yerde yeterli çarpı yok - önbellekteki girişin ilgili satırının silinmesi.
Çok fazla optimizasyon yapıyorum. Bazıları artık alakalı değil. Ve bu seçenekleri kaldırmak için hiçbir mekanizma yoktur. Bazen koca bir liste ortaya çıkar ve seçeneğinizi gereksizler arasında aramaya başlarsınız.
Bu nedenle, lütfen resimde gösterilen yerde haç üzerindeki gereksiz verileri silmeyi düşünün.
Çalışma hatası
Sonuç: doğru:yanlış:7:4
Sanki farklı uzunluktaki bu diziler birdenbire eşit miydi? StringCompare ile karşılaştırırken tam tersi == sonucu verir
Mesaj için teşekkürler, karakter karakter dizi karşılaştırmasının davranışını değiştirdi.
Daha önce diziler Z dizileri olarak (boş karaktere kadar) karşılaştırıldıysa, şimdi PASCAL dizileri olarak karşılaştırılıyorlar (uzunluk dikkate alınarak).
"Normal" dizeleri olan (içeride Z-boş karakter olmayan) mevcut kodlar bu değişiklikten etkilenmeyecektir.