Hatalar, hatalar, sorular - sayfa 2165
Alım-satım fırsatlarını kaçırıyorsunuz:
- Ücretsiz alım-satım 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
Negatif değerler için bir optimizasyon grafiği oluşturmuyorum.
Optimizasyon sonuçlarında veriler var.
Uzman Danışmanlarınızda negatif değerler ayarlamaya çalışın. Değerler doğrulama için * -1 olabilir.
Çek şunu gösterdi:
Bu kod, aşağıdaki montajcı SSE koduna dönüşür:
Sonuçta bu bir sanat eseri. Montajcı komutunun 4 çağrısı için 8 kök hesaplanır. Bir aramada iki çift sayı hesaplandı.
Genel sonuç: MQL5'teki matematik, mükemmel optimizasyon sayesinde kazanır. Kaybeden diziler değil, matematik kazanır.
Değerli bilgiler için çok teşekkürler.
Haber tabii ki daha sevindirici. Bu gerçekten havalı!
MQ'nun yakışıklı olduğunu her zaman söylemişimdir!
Ancak, veri türlerini karıştırırken son derece dikkatli olmanız gerektiğini de anlıyorum. Ama önceden uyarılmış, önceden hazırlanmış demektir.
Bu ışıkta geliştiricilerden bazı öneriler almak harika olurdu.
Şimdi hem sıradan değişkenlerin hem de dizilerin türlerini deneyeceğim. Ne olduğu ilginç.
denendi.
Bir şekilde bulmacalarım uymuyor.
İki seçenek yaptı. İlk - maksimuma, her şeyi int türüne aktardı. İkincisi ikili.
Evet, biraz daha hızlı oldu. Ancak ana frenler hala mevcut.
İşte int seçeneğine sahip ana fren bloğu:
sadece int tipi vardır ve tip karıştırma yoktur. Aynı zamanda, SQRT dizisinin kendisi int oldu.
Yalnızca yüzde 10 daha hızlı çalışır.
C varyantı benzer bir resmi ikiye katlar.
Eh, her şey aynı, sadece bir durumda sqrt () işlevi hesaplanırken, türlerin bir karışımı var.
Ve ikinci durumda, bir int dizisine erişilir ve tip karıştırma yoktur ve teoride sadece ALU kullanılmalıdır.
Ve ikinci seçenek 3 kat daha yavaşken. Eh, biri ne derse desin, nedeni bir dizidir.
Ve bir önemli nokta daha.
int örneğinde, tuval 100x100 ise, yani. bu ayarlarla
daha sonra diziye erişirken hız kazancı elde ederiz.
Onlar. 20.000 boyutunda bir SQRT dizisi kullandığımızda %15-20, 3.000.000 kullandığımızda ise tamamen aynı matematikle %200 kaybediyoruz.
Dizinin boyutu frenlerin nedeni mi?
İnsanlar, modern C++ derleyicilerinin çıktısını anlama yeteneğini uzun süredir kaybettiler.
Ek olarak, koddan salata sosu / çöpünüz var, bu da saf aksiyomlar oluşturmak için neredeyse sıfır fırsat anlamına geliyor “eğer böyle koşullar varsa, sonuç böyle olacaktır”. Yani, son optimizasyon her şeyi o kadar çok yeniden oluşturacak ki, koddaki yetersiz değişikliklerle bile hipotezleriniz yüzde onlarca farklı sonuç verecektir.
8 kökün 4 montaj talimatına sıkıştırılmasına bir kez daha bakın ve hiçbir şey iddia etme, talep etme veya mantığınıza hitap etme şansınız olmadığını anlayın. Optimize ediciler, uzun süredir programcıların erişemeyeceği aşkın seviyelerde çalışmaktadır.
Derleyicinin kökleri ayrıştırma şekli bir sanattır. Ve en basit sınırlamayı bile anlamadan onu dizilerle yenmeye çalışıyorsunuz - bir diziden okumak zaten bir başarısızlık. Mükemmel kayıt işlemi ve toplu köke karşı dallanma (cezalar) ve sık önbellek kayıplarıyla bellek tırmanışı.
İşlemcinin L1 / L2 / L3 önbelleklerini hiç bilmediğiniz için “neden küçük bir tamponda daha hızlı çalışıyor, ancak büyük bir tamponda sağır edici bir şekilde birleşiyor” sorusunu soruyorsunuz. Önbelleğe basın - hızlı bir şekilde sayılır. Vurmadı - üst önbellek veya bellekten birkaç düzine veri okuma döngüsü bekleyin.İnsanlar, modern C++ derleyicilerinin çıktısını anlama yeteneğini çoktan kaybetti.
Ek olarak, koddan salata sosu / çöpünüz var, bu da saf aksiyomlar oluşturmak için neredeyse sıfır fırsat anlamına geliyor “eğer böyle koşullar varsa, sonuç böyle olacaktır”. Yani, son optimizasyon her şeyi o kadar çok yeniden oluşturacak ki, koddaki yetersiz değişikliklerle bile hipotezleriniz yüzde onlarca farklı sonuç verecektir.
8 kökün 4 montaj talimatına sıkıştırılmasına bir kez daha bakın ve hiçbir şey iddia etme, talep etme veya mantığınıza hitap etme şansınız olmadığını anlayın. Optimize ediciler uzun zamandır programcıların erişemeyeceği aşkın seviyelerde çalışıyor.
VS ile karşılaştırma sonuçlarınızı çok iyi görebiliyorum ve bundan çok memnunum.
Ama soru açık kalıyor.
Kaotik çalışma kodu için özür dilerim, ancak bu yalnızca kodun bu bölümü ve iki yürütme seçeneğinin karşılaştırılması ile ilgilidir:
Burada çöp yok.
" Dinamik dizi erişim optimizasyonu övgünün ötesinde mükemmel" dediniz.
Ama... önceki mesajıma bakın.
Son denememi nasıl açıklarsınız?:
"Yani, boyutu 20.000'lik bir SQRT dizisi kullandığımızda %15-20 kazanıyoruz ve 3.000.000 kullandığımızda tamamen aynı matematikle %200 kaybediyoruz.
Dizinin boyutu frenlere neden olur mu?"
Önceki cevabımı dikkatlice okuyun - kesin cevapla birlikte eklendi.
Sorularınızı basit bir şekilde açıklayacağım: İşlemcilerin tasarımına ilişkin beş teknik makaleyi performans ve onu etkileyen faktörler açısından dikkatlice okuyun. Onsuz, tartışamazsınız çünkü temel şeyleri açıklamanız gerekir.
Derleyicinin kökleri ayrıştırma şekli bir sanattır. Ve en basit sınırlamayı bile anlamadan onu dizilerle yenmeye çalışıyorsunuz - bir diziden okumak zaten bir başarısızlık. Mükemmel kayıt işlemi ve toplu köke karşı dallanma (cezalar) ve sık önbellek kayıplarıyla bellek tırmanışı.
İşlemcinin L1 / L2 / L3 önbelleklerini hiç bilmediğiniz için “neden küçük bir tamponda daha hızlı çalışıyor, ancak büyük bir tamponda sağır edici bir şekilde birleşiyor” sorusunu soruyorsunuz. Önbelleğe basın - hızlı bir şekilde sayılır. Vurmadı - üst önbellek veya bellekten birkaç düzine veri okuma döngüsü bekleyin.Önceki cevabımı dikkatlice okuyun - kesin cevapla birlikte eklendi.
Sorularınızı basit bir şekilde açıklayacağım: İşlemcilerin tasarımına ilişkin beş teknik makaleyi performans ve onu etkileyen faktörler açısından dikkatlice okuyun. Onsuz, tartışamazsınız çünkü temel şeyleri açıklamanız gerekir.
Yaşasın!!!
En sonunda!
Sen Renat, içinden kerpetenle çekilmen gerekiyor.
Şimdi resim benim için daha net.
Derleyicinize sürdüğümde yanılmışım. İtiraf ediyorum, şeytan kandırdı. Bunun sebebinin işlemcinin sınırlı önbellekleri olduğu tahmin edilebilirdi. Modern işlemcilerde gerçekten kötüyüm ve gerçekten bu konuda okumam gerekiyor.
Ama yine de, bu kodu yazmam boşuna değildi - bir laboratuvar faresi ve bu dalgayı kaldırdı.
Bu yüzden, bu konuyu okuyan programcılar için, bu dalganın sonucunda kişisel olarak bulmayı başardıklarımı özetleyeceğim:
Bu bilgilerden yola çıkarak kodu düzeltmeye gitti. Dizilerin boyutunu sık sık kötüye kullandım.
Herkese teşekkürler!
artı düğmesine basıldığını veya bırakıldığını nasıl anlarız?
fare tekerleğinin tıklamasını yakalayabilirsiniz, ancak fare kullanılmıyorsa ne yapmalı?
artı düğmesine basıldığını veya bırakıldığını nasıl anlarız?
fare tekerleğinin tıklamasını yakalayabilirsiniz, ancak fare kullanılmıyorsa ne yapmalı?
Gerekirse zorla basabilir veya sıkabilir mi?
CHART_CROSSHAIR_TOOL
Orta fare düğmesine basarak "artı işareti" aracına erişimi etkinleştirin / devre dışı bırakın
bool (varsayılan doğru)
Gerekirse zorla basabilir veya sıkabilir mi?
CHART_CROSSHAIR_TOOL
Orta fare düğmesine basarak "artı işareti" aracına erişimi etkinleştirin / devre dışı bırakın
bool (varsayılan doğru)
Anladığım kadarıyla, bu yalnızca araca erişim, ancak kapatma değil.