Mql5 dilinin özellikleri, incelikleri ve çalışma yöntemleri - sayfa 117
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
Aklıma şu geldi:
Teoride, bu mümkün olan en hızlı olanıdır. Tüm hesaplamalar sabitlerle yapılır, bu nedenle derleme sırasında hesaplanırlar. Toplamda, hepsi sadece 6 ardışık karşılaştırmaya gelir ve daha fazlası değil. Ancak bu seçenek benim için öncekinden daha yavaş çalışıyor. sebebi nedir anlayamıyorum.
Aklıma şu geldi:
Teoride, bu mümkün olan en hızlı olanıdır. Tüm hesaplamalar sabitlerle yapılır, bu nedenle derleme sırasında hesaplanırlar. Toplamda, hepsi sadece 6 ardışık karşılaştırmaya gelir ve daha fazlası değil. Ancak bu seçenek benim için öncekinden daha yavaş çalışıyor. sebebi nedir anlayamıyorum.
İkiye bölmek sizi yavaşlatır mı? Shift ile değiştirmeyi dener misiniz? Hesaplanan sabitlerin - hemen hesaplanması gerektiği şüphesi (bu durumda - ve tanımdaki kayma - ayrıca bir sabitle değiştirilmelidir).
Ek olarak - "soru" - bildiğim gibi, bu oldukça tartışmalı bir operatör, bir yirmi yıl önce C ++ ile kontrol ettiler, bazen "soru" normal bir if ifadesinden daha uzun kod üretir. Belki burada da aynıdır?
Ve dönüş kodunu uint yapardım - imzalı ve imzasız değerleri dönüştürürken bazı kontroller yapılırsa ne olur?
Kendi başınıza deney yapmanın bir yolu olmasa da - işlemci gözbebeklerine yüklenir ... Hatta metin "fişlerle" yazılır ...
İkiye bölmek sizi yavaşlatır mı? shift ile değiştirmeyi dener misin? Hesaplanan sabitlerin - hemen hesaplanması gerektiği şüphesi (bu durumda - ve tanımdaki kayma - ayrıca bir sabitle değiştirilmelidir).
Ayrıca - "soru sorusu" - bildiğim gibi, bu oldukça tartışmalı bir operatör ...
Bir bölümü bir vardiya ile değiştirmenin bir etkisi yoktur. Ortaya çıkan ifadenin çok uzun olduğundan şüpheleniyorum, bu nedenle derleyici onu sonuna kadar optimize etmedi.
Ancak testleri Optimize=0 ile yaptım. Optimizasyon etkinleştirildiğinde her şey yerine oturdu: ikinci seçenek yaklaşık bir buçuk kat daha hızlı. Bingo!
Optimizasyon devre dışı bırakılırsa, ikinci seçenek küçük değerler için biraz daha yavaş, ancak büyük değerler için biraz daha hızlıdır. Kısacası, ikinci seçenek kesinlikle daha iyi.
Aklıma şu geldi:
Teoride, bu mümkün olan en hızlı olanıdır. Tüm hesaplamalar sabitlerle yapılır, bu nedenle derleme sırasında hesaplanır. Toplamda, hepsi sadece 6 ardışık karşılaştırmaya gelir ve daha fazlası değil. Ancak bu seçenek benim için öncekinden daha yavaş çalışıyor. sebebi nedir anlayamıyorum.
Bu doğru - seçeneğiniz en hızlısı.
Sadece boş bir test. Çok sık olarak, performans testi yapılırken önemli bir nokta unutulur: hesaplanan değer hiçbir yerde kullanılmazsa, derleyici basitçe hesaplamayı yapmaz.
Sonuçta, bu mantıklı - ne anlamı var? Kuantum süperpozisyonu gibi. Kimse bakmıyorsa ay neden var olsun ki? "Ay sadece bir fare ona baktığı için mi var oluyor?" (Albert Einstein). :))
Bu nedenle, sağlama toplamının hesaplanması ve yazdırılmasıyla testin bu sürümü daha doğru olacaktır:
Sonuç:
Ve ikinci sırada hala _FastLog2, log2 değil :))Sadece boş bir test. Çok sık olarak, performans testi yapılırken önemli bir nokta unutulur: hesaplanan değer hiçbir yerde kullanılmazsa, derleyici basitçe hesaplamayı yapmaz.
Sonuçta, bu mantıklı - ne anlamı var? Kuantum süperpozisyonu gibi. Kimse bakmıyorsa ay neden var olsun ki? "Ay sadece bir fare ona baktığı için mi var oluyor?" (Albert Einstein). :))
Bu nedenle, sağlama toplamının hesaplanması ve yazdırılmasıyla testin bu sürümü daha doğru olacaktır:
Kodunuz kafa karıştırıcı. Tanımlamada kullanılan değişkenler program kodunun diğer ucunda bulunur - bu tür kaosu anlamak elverişsizdir. Ancak mesele bu değil, testlerinizin sonuçlarının güvenilir kabul edilemeyeceği gerçeğidir, çünkü. derleyici, fonksiyona iletilen değerlerin algoritmasını önceden bilir. Bu nedenle testlerinizi optimize eder. Rastgele sayılara güvenmeniz gerekir.
Bu arada, neden kodunuzda srand var? İlk gördüğümde rastgele kullandığınızı düşündüm, ama aslında - hayır.
İşte kodum:
Kodunuz kafa karıştırıcı. Tanımlamada kullanılan değişkenler program kodunun diğer ucunda bulunur - bu tür kaosu anlamak elverişsizdir. Ancak mesele bu değil, testlerinizin sonuçlarının güvenilir kabul edilemeyeceği gerçeğidir, çünkü. derleyici, fonksiyona iletilen değerlerin algoritmasını önceden bilir. Bu nedenle testlerinizi optimize eder. Rastgele sayılara güvenmeniz gerekir.
Bu arada, neden kodunuzda srand var? İlk gördüğümde rastgele kullandığınızı düşündüm, ama aslında - hayır.
İşte kodum:
kod benim değil Az önce düzelttim ve sağlama toplamlarının kimliğini kontrol etmek ve nispeten pahalı Rand işlevlerini döngüden çıkarmak için Rand'ı attım ve srand onu atmayı unuttu.
rand'ı iade ediyorum. Haklısın - derleyici ardışık değerlerden logaritma toplamının döngüsünü optimize ediyor. Şaşırmış olmama rağmen. Bunu nasıl yaptığını anlamıyorum. Belki de hesaba katmadığımız bir şey vardır.
Sonuç:
Mevcut kazanan _FastLog2
Sonuç:
Mevcut kazanan _FastLog2
Değerler rastgele ise, her yerde aynı sağlama toplamını nasıl elde ettiğinizi merak ediyorum.
Değerler rastgele ise, her yerde aynı sağlama toplamını nasıl elde ettiğinizi merak ediyorum.
tüm işlevler için srand(45)
Ben de ilk başta yaptım ama farklı sağlama toplamları aldım, tk. rand()*rand() öğesinin 0 olabileceğini hesaba katmadı ve bu sağlama toplamını bozar. Şimdi sıfırdan uzaklaşmak için bir eklendi.
tüm işlevler için srand(45)
Ben de ilk başta yaptım ama farklı sağlama toplamları aldım, tk. rand()*rand() öğesinin 0 olabileceğini hesaba katmadı ve bu sağlama toplamını bozar. Şimdi sıfırdan uzaklaşmak için bir eklendi.
Ve özellikle hızı ölçmekten bahsediyorsak, neden aynı sağlama toplamına ihtiyacınız var? Bu durumda toplamın özü, derleyicinin kodu kesmesini engellemektir, hepsi bu. Ve srand(45) yaparak, testin tekrar optimize edilmesine izin vermiş olursunuz.
Bu arada, yaklaşık sıfır. FastLog2'de sıfır kontrolü yoktur, bu da buna göre avantajlı bir başlangıç sağlar. Ancak, doğru bir şekilde test edilirse, yine de log2'den bir buçuk ila iki kat daha yavaştır)
Ve özellikle hızı ölçmekten bahsediyorsak, neden aynı sağlama toplamına ihtiyacınız var? Bu durumda toplamın özü, derleyicinin kodu kesmesini engellemektir, hepsi bu. Ve srand(45) yaparak, testin tekrar optimize edilmesine izin vermiş olursunuz.
Burada derleyicinin yeteneklerini abartıyorsunuz. Kaldır srand(45) - sağlama toplamları farklı olacaktır, ancak hız sonucu korunacaktır.
Ayrıca, deneyin saflığı için hesaplamaların aynı olduğu gerçeği beni yönlendirdi, çünkü tüm işlevlerin ayrıntılarına girmedi. Bazen bir işlev parametresinin değeri, yürütme süresini etkileyebilir.
Özellikle aynı zamanda algoritmaların doğruluğunu kontrol etmek için.