Hatalar, hatalar, sorular - sayfa 2284
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
Sonuçta, keneler RAM'de saklanmaz. Anladığım kadarıyla bölümler halinde gerektiği gibi indirildi.
Gerçek keneler varsa, o zaman evet.
Tek geçişte istatistikleri, keneleri saklamak için ne kadar bellek harcandığını görebilirsiniz. Optimize ederken, aynı anda bellekte 320 megabayttan fazla saklanmaz. Diğer her şey diskte.
Şimdi tüm yerel ajanların bu bellekten okuyabilmesi için tüm onay işaretlerini paylaşılan bellekte tutmak için bir çözüm düşünüyoruz. O zaman disk erişimi olmayacak ve optimizasyon daha hızlı olacaktır.
Gerçek keneler varsa, o zaman evet.
Tek geçişte istatistikleri, keneleri saklamak için ne kadar bellek harcandığını görebilirsiniz. Optimize ederken, aynı anda bellekte 320 megabayttan fazla saklanmaz. Diğer her şey diskte.
Şimdi tüm yerel ajanların bu bellekten okuyabilmesi için tüm onay işaretlerini paylaşılan bellekte tutmak için bir çözüm düşünüyoruz. O zaman disk erişimi olmayacak ve optimizasyon daha hızlı olacaktır.
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.
Optimizasyon sırasında neden SSD'ye sürekli erişiliyor (ışık yüksek frekansta titriyor)?
İşte tam da bu yüzden kene kullanmıyorum, logaritmik bir veri yapısı kullanıyorum (bundan zaten bahsetmiştim), belirli bir anda birkaç bin tik, ardından birkaç bin dakikalık çubuk, 2000 M2, 2000 M5 , M10, M30, H1, H3, H6, H12, D1, W1... tüm MN1 çubukları.
Böyle bir eksiksiz geçmiş veri yapısı, herhangi bir zamanda bir milisaniyeden daha kısa sürede oluşturulur ve RAM'de yalnızca 1,5 MB alır (daha doğrusu, RAM'de bile değil, işlemci önbelleğinde). Ve bu yapıya uygun tüm algoritmalar uçup gidiyor.
Ne de olsa vizyonumuz aynı logaritmik ölçekte düzenlenmiştir: ne kadar uzağa bakarsak, küçük ayrıntıları o kadar az fark ederiz.
Tehdit Bu, çok uzak olmayan bir gelecekte bilgisayarlarda tüm bellek aygıtlarının (sabit disk, RAM, işlemci önbelleği) fiziksel olarak yalnızca bir aygıt olacağı, yani 13 sıfırlı bir rakam boyutundaki işlemci önbelleği olacağı zaman, o zaman ben de geçiş yapacağım. keneler :))
...
Gerçi, belki konu dışıyım çünkü. böyle bir veri yapısı ile, ampul optimizasyon sırasında da titreyecektir. Sonuçta, tiki hala yüklenecek :((
Gerçek keneler varsa, o zaman evet.
Tek geçişte istatistikleri, keneleri saklamak için ne kadar bellek harcandığını görebilirsiniz. Optimize ederken, aynı anda bellekte 320 megabayttan fazla saklanmaz. Diğer her şey diskte.
Şimdi tüm yerel ajanların bu bellekten okuyabilmesi için tüm onay işaretlerini paylaşılan bellekte tutmak için bir çözüm düşünüyoruz. O zaman disk erişimi olmayacak ve optimizasyon daha hızlı olacaktır.
İlk 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ıkla erişildi. 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.
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.
Renata sizin için yeterli değil) Ckoko, tarihin depolanmasını optimize etmek için önerildiğinden beri. Özellikle sıkıştırma için herhangi bir harcama yapmanız gerekmediğini düşünürsek (ve bu en yoğun kaynak gerektiren kısımdır), çünkü. veriler başlangıçta sıkıştırılmış sunucudan gelir. Ve ambalajsız formda, yalnızca sürekli kullanılan önbelleği saklayın ... Ancak burada dersler genellikle her zaman tarzda başlar: Kendinize daha büyük veya daha hızlı bir vida satın alamazsanız, MT'de yapacak hiçbir şeyiniz yoktur. Ve nedense her zaman yavaş VPS'den bahsediyoruz.
Renata sizin için yeterli değil) Ckoko, tarihin depolanmasını optimize etmek için önerildiğinden beri. Özellikle sıkıştırma için herhangi bir harcama yapmanız gerekmediğini düşünürsek (ve bu en yoğun kaynak gerektiren kısımdır), çünkü. veriler başlangıçta sıkıştırılmış sunucudan gelir. Ve ambalajsız formda, yalnızca sürekli kullanılan önbelleği saklayın ... Ancak burada dersler genellikle her zaman tarzda başlar: Kendinize daha büyük veya daha hızlı bir vida satın alamazsanız, MT'de yapacak hiçbir şeyiniz yoktur. Ve nedense her zaman yavaş VPS'den bahsediyoruz.
Paketlenmiş dizilerin ana sorununun dizinin herhangi bir öğesine hızlı erişim organizasyonu olduğunu bir kez daha tekrarlıyorum, sıralı okumaları değil. Bu nedenle, burada farklı bir sıkıştırma formatına (daha doğrusu bir depolama formatına bile) ihtiyaç vardır, ancak bunun ambalajının açılmasını ve paketlenmesini gerektirmeyen bir sıkıştırma formatına ihtiyaç vardır. ~Zip, png vb. gibi 10 katı sıkıştırma tabi ki çalışmaz ama 5 katı olabilir diye düşünüyorum.
Eh, gerçekten, eğer düşünürseniz, MqlRates'te bir dakika çubuğu hakkında bilgi depolamak (ve sadece dakika çubukları saklanır) kapalı, açık, yüksek, düşük altında, 8 * 4 = 32 bayt kadar tahsis edilir. Vakaların% 99'u bu değerler bir bayt bilgisinden daha az farklılık gösterir, yani. 8+1+1+1=11 bayt, geçmiş çubuklara eklemeseniz bile, zaten neredeyse yeterli. Ve vakaların %99'unda zaman önceki değerden tam olarak 60 farklıdır (yani vakaların %99'unda 1 bit bilgi yeterlidir - 60 veya 60 değil). Ve bunun için 8 bayt da ayrılmıştır.
Paketlenmiş dizilerin ana sorununun dizinin herhangi bir öğesine hızlı erişim organizasyonu olduğunu bir kez daha tekrarlıyorum, sıralı okumaları değil. Bu nedenle, burada farklı bir sıkıştırma formatına (daha doğrusu bir depolama formatına bile) ihtiyaç vardır, ancak bunun ambalajının açılmasını ve paketlenmesini gerektirmeyen bir sıkıştırma formatına ihtiyaç vardır. ~Zip, png vb. gibi 10 katı sıkıştırma tabi ki çalışmaz ama 5 katı olabilir diye düşünüyorum.
Diskte depolama hakkında konuşuyorsak, belirli bir öğeye erişmek mantıklı değil çünkü. dosya işleminin kendisi maliyetlidir. Bu nedenle, büyük bir parça hemen okunur. Örneğin, çubuk geçmişi dosyaları yıllara, keneler - aylara bölünür. Tabii ki, daha küçük ezmek daha iyi olsa da. Ve eğer genel olarak tarihi, paketlenmiş bir biçimde bellekte tutmaktan, her bir öğeyi anında açmaktan bahsediyorsanız, o zaman korkarım bu birkaç kişiye uyacaktır.
Az önce 256 MqlRates öğesinden oluşan blokları depolayan ve ortalama 2900 bayt alan bir depolama biçimi buldum (blok boyutu kayan olacak), yani. Beklediğim gibi 5 kat daha az olan bir MqlRates yapısı için 2900/256= ~ 12 bayt ayrılacak.
Böyle bir paketlenmiş MqlRates yapısının her bir öğesine erişim oldukça hızlıdır (2-3 toplam, 2-3 kontrol, 2-3 vardiya, yani neredeyse 1 nanosaniyeden fazla)
Diskte depolama hakkında konuşuyorsak, belirli bir öğeye erişmek mantıklı değil çünkü. dosya işleminin kendisi maliyetlidir. Bu nedenle, büyük bir parça hemen okunur. Örneğin, çubuk geçmişi dosyaları yıllara, keneler - aylara bölünür. Tabii ki, daha küçük ezmek daha iyi olsa da. Ve eğer genel olarak tarihi, paketlenmiş bir biçimde bellekte tutmaktan, her bir öğeyi anında açmaktan bahsediyorsanız, o zaman korkarım bu birkaç kişiye uyacaktır.
Diskte "sıkıştırılmış" bir biçimde saklanacak ve aynı biçimde belleğe de okunacaktır. Tam biçime dönüştürme yapılmayacak, yalnızca MqlRates yapısının belirli bir öğesini okuma anında bir hesaplama yapılacaktır. Ve beş kat daha az disk çalışması olacağı göz önüne alındığında, çok daha hızlı olacaktır.
Böyle bir paketlenmiş MqlRates yapısının her bir öğesine erişim yeterince hızlıdır
...
Diskte "sıkıştırılmış" bir biçimde saklanacak ve aynı biçimde belleğe de okunacaktır. Tam biçime dönüştürme yapılmayacak, yalnızca MqlRates yapısının belirli bir öğesini okuma anında bir hesaplama yapılacaktır.
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 çoğu kullanıcı 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.