Değişkenleri bir döngünün arkasında mı yoksa bir döngünün içinde mi bildiriyorsunuz? - sayfa 10

 
Vict :

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:

 char *st = new char [ 23 ];
memcpy(st, "12345678qwertyuioasdfgh" , 23 );
sum += st[i % 23 ];
delete [] st;
 
Alexey Navoykov :

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.

 public class Program
{
   public static void Main()
    {
         int count = ( int ) 10 e6;

        {
             var watch = System.Diagnostics.Stopwatch.StartNew();
             int sum = 0 ;
             for ( int i = 0 ; i < count; i++)
            {
                 string st;
                st = "12345678qwertyuioasdfgh" ;
                sum += st[i % 23 ];
            }
            Console.WriteLine( "Sum: {0}, Time: {1} ms" , sum, watch.ElapsedMilliseconds);
        }

        {
             var watch = System.Diagnostics.Stopwatch.StartNew();
             int sum = 0 ;
             string st;
             for ( int i = 0 ; i < count; i++)
            {
                st = "12345678qwertyuioasdfgh" ;
                sum += st[i % 23 ];
            }
            Console.WriteLine( "Sum: {0}, Time: {1} ms" , sum, watch.ElapsedMilliseconds);
        }

        Console.ReadKey();
    }
}

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.

 
Alexey Navoykov

Burada önce frenlerin nedenlerini anlamanız gerekir. Biraz kazdım, arama dışında her şey orada satır içi

 0x41a727 <main()+ 119 >   callq   0x48e1a0 <_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceEmmPKcm>

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))).

Использование модулей C++ в Visual Studio 2017
Использование модулей C++ в Visual Studio 2017
  • habr.com
Команда Visual C++ рада сообщить, что в Visual Studio 2017 было существенно улучшено качество реализации модулей C++ согласно технической спецификации; также мы добавили возможность подключать Стандартную Библиотеку C++ через интерфейсы модулей. Эти интерфейсы, как и поддержка модулей компилятором, являются экспериментальной разработкой и будут...
 
Alexey Navoykov :

İ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...

 
Vict :

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:

 char *str = new char [ 23 ];
...
delete str;


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

 
Alexey Navoykov :

Ö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

Anlamıyorsun, ben başka bir şeyden bahsediyorum. Genel olarak, test bir oyuncaktır - yükü olmayan çıplak bir döngü. Size söylemeye çalıştım - kayıpların sıralanamayan işlev çağrılarında olduğunu. Artı modülleri daha iyi test edin, sonuç orada daha ilginç, ancak hala bitmemiş olabilir.
 
Alexey Volchanskiy :

B-rr-rr, evet olamaz! Sharp her zaman temiz artılarla her iki seferde birleştirilir, projeyi plz ortaya koyarsınız.

Dosyalar:
Project1.zip  1671 kb
 
Vict :
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.

Neden: