Standart özelliklerin/yaklaşımların alternatif uygulamaları - sayfa 11
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
linki bırak lütfen
Kaydetmedi. Burada forumda bahsedildi. Arama motorlarından araştırdım.
Kaydetmedi. Burada forumda bahsedildi. Arama motorlarından araştırdım.
Tüm bu bisikletlerin bir zamanlar birçok kez yeniden yapıldığı açıktır. Asm-uygulamalarına kadar kitaplar bile çıktı.
Şimdi temelleri bulmak zor çünkü. hemen hemen herkes, tüm durumlar için uygun API'leri kullanır.
Bu nedenle, forumlara kaydolmanız ve sormanız yeterlidir.
Tüm bu bisikletlerin bir zamanlar birçok kez yeniden yapıldığı açıktır. Asm-uygulamalarına kadar kitaplar bile çıktı.
Şimdi temelleri bulmak zor çünkü. hemen hemen herkes, tüm durumlar için uygun API'leri kullanır.
Bu nedenle, forumlara kaydolmanız ve sormanız yeterlidir.
Neden LONG_MAX/MIN kullanmıyorsunuz? Bir şekilde daha iyi görünecek. Hiçbir şeye benzemiyor. Testlerinizi gcc üzerinde çalıştırdım (minik bir değişiklikle, elbette derleyici çok eski 5.4.0'dır ki bu da elinizin altındaydı):
Evet, güzel değil. Ancak LONG_MAX = 9223372036854775807, 9007199254740992'den büyüktür. sadece ulong tipi için görülebilir. Nasıl daha iyi hale getireceğimi bile bilmiyorum. (ulong)(1<<53) yazmayın, çünkü bu zaman alan bir işlemdir.
Double türü, LONG_MAX değerinden değil, mümkün olan maksimum mantisten kesirli bir parçası olmayan tamsayıları içermeye başlar. Ve mantis için 53 bit ayrılmıştır, yani. 2^53=9007199254740992.
Kodunuzda, zaman hesaplaması önemsizdir - çıktı milisaniye cinsindendir (nano değil) ve hala eksi t0'ın neden gerekli olduğunu anlamıyorum.
t0, basit çift toplamın 1000000 geçişlik tam döngüsünün zamanıdır.
ve t, aynı çift değerlerin toplamının aynı döngüsünün zamanıdır, ancak tavan, Tavan, yuvarlak vb. işlevlerden geçer.
Farkın (t-t0) bu fonksiyonlar için harcanan net zaman olduğu mantığından hareket ettim.
Tabii ki, daha fazla objektiflik ancak birkaç ölçüm alarak elde edilebilir.
- nano'da 1.000.000 fonksiyondan birinin yürütme süresine göre hesaplıyorum, nano'da doğru.
pavlick_ :
Testlerinizi gcc üzerinde çalıştırdım (minik bir değişiklikle, elbette derleyici çok eski 5.4.0'dır ki bu da elinizin altındaydı):
1. -O3 ile derleme
2. -Ofast ile Derleme
(ulong)(1<<53) yazmayın, çünkü bu zaman alan bir işlemdir.
Bu işlem, dizeler dahil sabitleri olan tüm işlemler gibi zaman almaz.
Bu işlem, dizeler dahil sabitleri olan tüm işlemler gibi zaman almaz.
Vay havalı! Teşekkür ederim. Ve düşündüm - her zaman önemlidir. Evet, mantıklı, derleme aşamasında zaten hesaplayabilirsiniz.
Sonra şöyle:
Doğru, 53 yerine DBL_MANT_DIG yazmak daha doğru olur.
Tüm çift değerler kesirli ise minimum kazanma durumu.
Bu işe yarayan bir şey. Bu derlenmiş MQL5 kodu, Ofast'tan bile daha hızlı mı? İnanması zor. Muhtemelen orada 32 bitlik bir derleyiciniz vardı.
Her yerden eksi t0 attım (bir tür hata olduğunu düşündüm) ve çıktımda sadece bir geçiş değil, tüm döngü donmuştu. Bunu yineleme başına nanosaniye cinsinden çıktı biçiminize getirirsek (ilk satırda "Yuvarlamasız döngü süresi" - hesaplama yöntemi bizim için aynıdır), o zaman şunu elde ederiz:
gcc'de özel bir hızlanma yoktur (ve hatta -Ofast'ta daha yavaştır). Testinize göre µl başına anlamlıdır, ancak:
1'000'000 üzerinden 985'651'iniz var, yani hemen hemen tüm yinelemeler x < MIN || koşulunu karşılar. x > MAKS.
-Ofast, inf/nan için tüm kontrolleri devre dışı bırakır, errno ayarını yapar, yani fpu üzerinde çıplak yuvarlama kalır. Ve bu çıplak yuvarlama, en basit karşılaştırma ile aşılamaz x < MIN || x > MAKS.
Gcc'de özel bir hızlanma yoktur (ve hatta -Ofast'ta daha yavaştır). µl başına önemli
Nasıl söylenirse de. Güzel sayılar için t0 attık ve 20 kat fark elde ettik. Bir döngü (+t0) biçimindeki minimum ek kod bile, iki kez bölgede birkaç düzine kat daha az çekici güzel bir sonuç yapar. Ve eğer bu bir çıplak döngü değil de faydalı bir şeyler yapan gerçek bir algoritmaysa ne söyleyebilirim? Evet, fark hiç görünmeyecek, ondalık noktadan sonra bir yerde kalacak ve bir darboğaz olması muhtemel değil. Gerçek bir uygulamada, bir muteks, CPU engelleri almak, bellek ayırmak yuvarlamadan çok daha pahalıdır. Genel olarak, IMHO, muma değmez.
Evet, fark hiç görünmeyecek, ondalık noktadan sonra bir yerde kalacak ve bir darboğaz olması muhtemel değil. Gerçek bir uygulamada, bir muteks, CPU engelleri almak, bellek ayırmak yuvarlamadan çok daha pahalıdır. Genel olarak, IMHO, muma değmez.
Bu, zamanın %99'unda doğrudur, evet.
Optimize etmeden önce, neyin optimize edileceği konusunda endişelenmeye değer.
Uygulamamda, kendi atof uygulamamın gerçekten yardımcı olduğu tek bir vakayı hatırlıyorum. Öyle görünse de.
Ve herhangi bir optimizasyonun (optimizasyon *** hariç) hiçbir şekilde ücretsiz olmadığını hatırlamakta fayda var.