yardıma ihtiyacım var! Görev çözülmedi, demirin sınırlamalarıyla karşılaşıyorum - sayfa 19
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
Bu nedenle, diğer dizilerden birkaç milyon işlemi sıralamak gerekecek! İşte tam da bundan bahsediyorum.
Eh, tek bir sayıyı (sıra numarası) kontrol etmekten bahsediyoruz, böyle basit bir işlem için bir milyon çok fazla değil. Kriteri yinelemeli olarak ele alırsanız, bu dosyanın yalnızca bir geçişidir, o zaman yine de yapmanız gerekecektir. Başka bir şey, özyineleme için verilerin "haritasının" aynı birkaç milyon öğe olacağıdır (bir dizi için parametre sayısıyla çarpın).
Bir alternatif de mümkündür - sıralamadan önce ezberleme ile kriterin sürekli hesaplanması. Yine, özyinelemeyi kullanma yeteneği çok önemlidir.
Herhangi biri için birçok işlem olacağı açık, ancak orijinal versiyonda bunlardan daha azı var mı?
C++'da aşağıdaki durumlarda ayrıştırıcı olmadan mümkündür:
Fikri 10 kez zorluyorum - başka bir dosyadaki dizilerin konumlarının başlangıç değerleriyle başka bir dosya oluşturmak için, o zaman işlem sayısının dizi yapısında saklanmasına bile gerek kalmayacak.
Daha önce bahsedilen normal dizini alacaksınız.
Yukarıda açıklanan algoritmayı uyguladı.
Verilerimi X = 20'de işlemek (20 işlem için kriteri hesaplamak) yaklaşık 112 dakika sürdü (tam olarak fark etmedim), aslan payı dizi kayması tarafından yenildi (profilci tarafından değerlendirildiğinde %40).
Dizileri döngüye soktuktan ve diğer bazı optimizasyonlardan sonra, işleme aşağıdakileri almaya başladı:
Yalnızca 65 işlem için yeterli bellek vardı (bir milyon diziyle çarpın). Bu elbette yeterli değil, en az 100'e güvendim.
Bir sonraki adım, işlemlerle ilgili tüm gereksiz bilgileri atmaktı. Sadece açılış ve kapanış saatleri ve puan olarak kâr bırakarak X = 185'ten çıkmayı başardık.
Sonraki - sadece dosyayla çalışmayı hızlandırın, FileReadXXX şimdi zamanın% 30'unu alıyor (ve dağıtıcı diskle çalışma olmadığını, yalnızca işlemcinin yüklendiğini söylüyor).
FileRead - özellikle FileSeek'ten sonraki ilk, yani. sıralı okuma hızlıdır.
Yeni sonuçlar hakkında sizi bilgilendireceğim.
C++'da bu, 64K-128K arabelleğine girerek yapılır, sscanf'ler çok yavaş olduğundan, onu kendi ayrıştırıcınızla ayrıştırmak daha iyidir.
Dosyalarla WinAPI üzerinden çalışmayı deneyeceğim, aslında bu hizmet masası bana şunları tavsiye etti:
Fikri 10 kez zorluyorum - başka bir dosyadaki dizilerin konumlarının başlangıç değerleriyle başka bir dosya oluşturmak için, o zaman işlem sayısının dizi yapısında saklanmasına bile gerek kalmayacak.
Endeksin ne vereceğini anlamıyorum.
İşlem sayısını kaydetmek çalışmıyor, sıralı okuma hızlı çalışıyor, sorun dosya içinde hareket ettikten sonra bloğu okumakta.
Lütfen önerilen eylem algoritmasını yazın.
Görev önemsiz değil, ancak henüz tek bir kod satırı yok. Andrey, buradaki birçok kişi ilgileniyor - bir problem formüle edin, test verileri sunun. Spor programlarını düzenleyin.
Verilerle çalışmak için genel ilkelerle birlikte test verilerine + sözde koda ihtiyacımız var.
Görev, başlangıç ve bitiş olarak formüle edilmiştir.
Ve test verileri, daha önce tarafımdan gönderilen, biraz değiştirilmiş bir komut dosyasıyla oluşturulabilir.
Biraz sonra yapacağım.
seçenekleri temelde sıralamak için ne için? kriterlere göre tarih üzerinde anlaşmalar oluşturmak daha iyi olabilir mi? olumsuzluk? Olması gerekenle aynı değil mi?
Testler için ise, elbette, evet, ancak bir sorunu çözmek için ise, elbette hayır)
samimi :
Eh, tek bir sayıyı (sıra numarası) kontrol etmekten bahsediyoruz, böyle basit bir işlem için bir milyon çok fazla değil. Kriteri yinelemeli olarak ele alırsanız, bu dosyanın yalnızca bir geçişidir, o zaman yine de yapmanız gerekecektir. Başka bir şey, özyineleme için verilerin "haritasının" aynı birkaç milyon öğe olacağıdır (bir dizi için parametre sayısıyla çarpın).
Bir alternatif de mümkündür - sıralamadan önce ezberleme ile kriterin sürekli hesaplanması. Yine, özyinelemeyi kullanma yeteneği çok önemlidir.
Herhangi biri için çok fazla işlem olacağı açıktır, ancak orijinal sürümde gerçekten daha azı var mı?
Orijinal versiyonda, geçmiş tarihten son anlaşmayı bulurken kriteri bir kez hesaplayabilirsiniz.
Ve sürümünüzde, tüm dizilerin X işlemine uyması için dosyanın böyle bir parçasını okumanız gerekir. Bu, X * dizi sayısından çok daha fazla olacaktır, çünkü farklı sayıda işlem vardır ve bunlar eşit olarak dağıtılmayabilir.
2 hepsi:
Her durumda, destek için teşekkürler.
Zor değilse, test komut dosyanızı çalıştırın ve sonuçları paylaşın.
Ve test verileri, daha önce tarafımdan gönderilen, biraz değiştirilmiş bir komut dosyasıyla oluşturulabilir.
Güncellenmiş bir komut dosyası ekliyorum, şimdi yalnızca aynı işlemleri kaydetmekle kalmıyor, belirtilen ayarlarla rastgele diziler oluşturuyor ( ömür - başlangıç ve bitiş, kâr - başlangıç ve bitiş).
Benimkiyle karşılaştırılabilir bir dosya elde etmek için komut dosyasını varsayılan seçeneklerle çalıştırın:
2014.08.28 04:12:36.044 sTest_ReadWriteBIN EURUSD,M15: 57.1 saniyede yazılmış 140000 secuences
2014.08.28 04:13:20.688 sTest_ReadWriteBIN EURUSD,M15: 6632 Mb 44.0 saniyede yüklendi ( 150,7 MB/sn )
Bundan sonra, üzerinde algoritmayı çalıştırabilirsiniz.
En tembeller için - Google Drive'da bir dosya içeren bir arşiv.
komposter :
1. Orijinal versiyonda, geçmiş tarihten son anlaşmayı bulurken kriteri bir kez hesaplayabilirsiniz.
2. Ve sürümünüzde, tüm dizilerin X işlemine uyacak şekilde dosyanın bir parçasını okumanız gerekiyor. Bu, X * dizi sayısından çok daha fazla olacaktır, çünkü farklı sayıda işlem vardır ve bunlar eşit olarak dağıtılmayabilir.
1. Bu çok net değil, eğer kriterin maksimumunu (minimumunu) arıyorsak, sonuçta yine de tüm adaylar için kriteri hesaplamamız gerekiyor. Yerel veya küresel bir ekstremum aranıyor olsa bile fark etmez.
2. Daha çok, sorunun gerekli bellek açısından kabul edilebilir bir boyutta olup olmadığı açıktır. Ayrıca, disk okuma hızı açısından daha büyük bir blok boyutu teoride daha da iyidir. Tabii şu ana kadar RAM için sorun yaratmıyor. Okumanın sırayla ve yalnızca bir kez gerçekleşmesi temelde önemlidir.
Sıralamadan önce kriterin hesaplanması seçeneği, gerçekten iki kez okumayı gerektirir. Ancak, özellikle verileri birkaç küçük dosyaya bölme ve bunları müteakip ortak işleme olasılığı göz önüne alındığında, avantajlar vardır.
Ancak, bir uygulama olmadan, tüm argümanlar soyut kalacaktır. Bu yüzden tartışmanın bu noktasında, benim veda etmem uygun olur :)
Dosyaları dikebilir misin? hangi bitin hangi dosyanın başında ve sonunda olduğu indeksleme ile.
Örneğin, lam dosyalarından 1000 başlangıç meta dosyasından 1000 meta dosyası yapın ve kriterler biliniyorsa, benzer dosyaların bir meta dosyada kalıplanması için istatistiksel sıralama yapın.
Tehdit, ancak FileOpen ile denemek daha iyidir, büyük bir dosyayı 1000 küçük dosyaya eşit hacimde 1000 kez açmak veya küçük bir dosyayı 1000000 kez açmak anlamında büyük bir dosyayı veya küçük bir dosyayı açmak nasıl daha hızlı çalışır?
Ve dosyaların dikilmesi gerekmediği, ancak bölündüğü ortaya çıkabilir.
Dosyaları dikebilir misin? hangi bitin hangi dosyanın başında ve sonunda olduğu indeksleme ile.
Örneğin, lam dosyalarından 1000 başlangıç meta dosyasından 1000 meta dosyası yapın ve kriterler biliniyorsa, benzer dosyaların bir meta dosyada kalıplanması için istatistiksel sıralama yapın.
Tehdit, ancak FileOpen ile denemek daha iyidir, büyük bir dosyayı 1000 küçük dosyaya eşit hacimde 1000 kez açmak veya küçük bir dosyayı 1000000 kez açmak anlamında büyük bir dosyayı veya küçük bir dosyayı açmak nasıl daha hızlı çalışır?
Ve dosyaların dikilmesi gerekmediği, ancak bölündüğü ortaya çıkabilir.
Şu anda büyük bir dosya üzerinde çalışıyorum ama milyonlarca küçük dosyaya gitmek istedim.
İlk olarak, eklenebilirler ve ikinci olarak, adlarına göre erişilebilirler ("her dizinin başlangıcını" kaydetmeye gerek yoktur).
Servis masasında, yaklaşık bir milyon farklı dosya açılımı sordu (önbellek benim için bu şekilde uygulandı). Cevap açık ve anlaşılır.
Bir büyük dosya ve bir milyon küçük dosya için API fonksiyonlarını test edeceğim, sonuçları yayınlayacağım.
Ancak, bir uygulama olmadan, tüm argümanlar soyut kalacaktır. Bu yüzden tartışmanın bu noktasında, benim veda etmem uygun olur :)
İşte başlamalıydım ;)
Ancak her durumda, girdiniz için teşekkürler, kod içermeyen fikirler de değerlidir.
Bir milyon dosyayla, ntfs'yi o kadar mahvedeceksiniz ki, herkesi sonsuza dek dosya sisteminin delice yavaş uygulanmasına kilitleyen bu çılgın Microsoft ürününden ağlayacaksınız.
ms'nin dosya sistemlerine yaptığı her şey canavarca ağırlıklar, durgunluk ve aptallıktır. Kahretsin, bu aptallar optimizasyon ve hız için herhangi bir çaba göstermediler ve api sadece ilkel. 2014'te bu açıkça söylenebilir. Ağla.
Windows'ta bir grup dosyayla çalışmanın verimliliğini artırmak isteyen herkes, her şeyden önce parçalara ayrılır - tek bir dosya içinde gruplama ve kendi veri yapısı .
Windows'ta binden fazla (ve hatta on binlerce yüz binlerce) dağınık dosyayı depolamaya başladığınızda, buradasınız.
MQL4/5'teki dosya işlemleri, çok verimli ve yüksek okuma ve yazma hızlarına ulaşmamızı sağlayan çok verimli önbelleğe alma mekanizmalarımızdan geçer.
Hatta bayt bazında veri akışı yapabilirsiniz - bunların tümü önce dahili arabellekte hızlı bir şekilde toplanır ve diske yalnızca büyük parçalar halinde yazılır. WinAPI çağrılarının sayısı minimumdur, bu da yüksek performans sağlar. Okuma benzerdir - proaktif olarak çalışır, büyük parçalar halinde çıkarır, WinAPI'ye çok nadiren erişir ve minimum ek yük ile önbelleğinden çok hızlı bir şekilde veri döndürür.
Kabaca konuşursak, 509 derlemesine kıyasla, MQL4/5'teki dosya işlemlerinin hızını bir büyüklük sırasına göre artırdık (hayali sürümden değil de olağan parçalı çalışmadan bahsedersek, "megabayt bloklar halinde yazıyoruz" hız ölçümü").