Değişkenleri bir döngünün arkasında mı yoksa bir döngünün içinde mi bildiriyorsunuz? - sayfa 10
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
zaman = 1018
toplam = 894782460
zaman=371
toplam = 894782460
Hz. neden, ama µl çok ileride (ve Rand() ile daha şık seçenekler).
Ve benim için açık - bir döngüye katlanmak.
Evet, haklısın, VS'de de denedim - nedense, hiçbir şey optimize edilmedi, bu kadar basit bir seçenek gibi görünse de ... Aslında, şuna kadar kaynar:
Evet, haklısın, VS'de de denedim - nedense, hiçbir şey optimize edilmedi, bu kadar basit bir seçenek gibi görünse de ... Aslında, şuna kadar kaynar:
Proje ayarlarında tüm optimizasyonu açtınız mı? Anlaşılmaz durumlarda, bir montajcı listesinin oluşturulmasını açarım ve ona bakarım, çok bilgilendirici bir ders.
İlgi uğruna, C# ile de test etmeye karar verdim. Sonuçlar yalnızca pratik olarak hız açısından birbirinden farklı olmakla kalmaz, aynı zamanda C++'dan çok daha hızlı çalışırlar.
Sonuçlar:
Toplam: 894782460, Süre: 69ms
Toplam: 894782460, Süre: 56ms
Ve işte C++'daki karşılığı:
Toplam: 894782460, Süre: 2947ms
Toplam: 894782460, Süre: 684ms
VS 2019'da test ediliyor . Tüm optimizasyonlar etkinleştirildi.
Fırında böyle C ++)
ps C#'daki sonuçlar testten teste fark edilir şekilde atlar, ancak ortalama olarak her iki seçeneğin de hızda aynı olduğu ortaya çıkar.
Burada önce frenlerin nedenlerini anlamanız gerekir. Biraz kazdım, arama dışında her şey orada satır içi
hangi libstdc++ içindedir. Onlar. Neredeyse çıplak bir döngünün arka planına karşı, işlev çağrılarının kendileri darboğaz haline gelir (peki, ayrıca ...replaceEmmPKcm'den gelen birkaç çağrı vardır). Sonuçta derleyici tek bir çeviri birimi içinde optimize edebilir. Burada LTO'yu (bağlantı zamanı optimizasyonu) kullanmayı deneyebilirsiniz, yani. bu, bağlantı aşamasında optimizasyona izin verecektir. Ama çok kullanmadım, şimdi hemen yapmayacağım. Pekala, özellikle karmaşık bir şey yok - -flto seçeneğini derleyiciye/bağlayıcıya iletmek için (bir tür eklentim olmamasına rağmen), kısacası, çözemeyecek kadar tembelim + yeniden inşa etmem gerekebilir libstdc++.
Peki, modüllerin (C ++ 20 ile başlayan) vidalanmasıyla bağlantılı olarak kodun optimizasyonu nasıl olacak? Bilmiyorum, her şey nemli ve deneysel olmasına rağmen tersine çevirebilirsiniz https://habr.com/en/company/pvs-studio/blog/328482/
c++' özleyeceksiniz))).
İlgi uğruna, C# ile de test etmeye karar verdim. Sonuçlar yalnızca pratik olarak hız açısından birbirinden farklı olmakla kalmaz, aynı zamanda C++'dan çok daha hızlı çalışırlar.
Sonuçlar:
Toplam: 894782460, Süre: 69ms
Toplam: 894782460, Süre: 56ms
Ve işte C++'daki karşılığı:
Toplam: 894782460, Süre: 2947ms
Toplam: 894782460, Süre: 684ms
VS 2019'da test ediliyor . Tüm optimizasyonlar etkinleştirildi.
Fırında böyle C ++)
ps C#'daki sonuçlar testten teste fark edilir şekilde atlar, ancak ortalama olarak her iki seçeneğin de hızda aynı olduğu ortaya çıkar.
B-rr-rr, evet olamaz! Sharp her zaman temiz artılarla her iki seferde birleştirilir , projeyi plz ortaya koyarsınız.
Küçük çocuklar :)
Oyuncağı 10 sayfa uzattılar...
Burada önce frenlerin nedenlerini anlamanız gerekir. Biraz kazdım, arama dışında her şey orada satır içi
hangi libstdc++ içindedir.
Öyle görünüyor ki, bu durumda bile, her seferinde hafızayı ayırdığını ve sildiğini öğrendiler:
Bu arada, geçen sefer yanlış sonuçlar vermiş olabilirim. Büyük olasılıkla x86 modundaydı. Şimdi x64'te test ediyorum - C ++'daki sonuçlar çok daha iyi:
1) ~ 2000ms
2) ~200ms (3x hızlandırılmış)
Doğru, Studio'yu da en son sürüme güncelledim, görünüşe göre bu da etkiledi, çünkü. x86 bile artık geçmiş ölçümlerden daha hızlı.
Genel olarak, şimdi C ++ Sharpe'ı utanç verici bir şekilde tüketmiyor. Toplamda yaklaşık 3 kez
Öyle görünüyor ki, bu durumda bile, her seferinde hafızayı ayırdığını ve sildiğini öğrendiler:
Bu arada, geçen sefer yanlış sonuçlar vermiş olabilirim. Büyük olasılıkla x86 modundaydı. Şimdi x64'te test ediyorum - C ++'daki sonuçlar çok daha iyi:
1) ~ 2000ms
2) ~200ms (3x hızlandırılmış)
Doğru, Studio'yu da en son sürüme güncelledim, görünüşe göre bu da etkiledi, çünkü. x86 bile artık geçmiş ölçümlerden daha hızlı.
Genel olarak, şimdi C ++ Sharpe'ı utanç verici bir şekilde tüketmiyor. Toplamda yaklaşık 3 kez
B-rr-rr, evet olamaz! Sharp her zaman temiz artılarla her iki seferde birleştirilir, projeyi plz ortaya koyarsınız.
Artı modülleri daha iyi test edin, sonuç orada daha ilginç, ancak hala bitmemiş olabilir.
Baktım, tek bir derleyicinin https://en.cppreference.com/w/cpp/compiler_support modüllerini tamamlamadığı ortaya çıktı, bu yüzden izlenecek bir şey yok.