Optimizasyon seviyesi -O3 g ++ 'da tehlikeli midir?

Çeşitli kaynaklardan (çoğunlukla bir meslektaşımdan olsa da) duydum, -O3g ++ ' da bir optimizasyon seviyesi ile derlemenin bir şekilde' tehlikeli 'olduğunu ve gerekli olduğu kanıtlanmadıkça genel olarak kaçınılması gerektiğini duydum .

Bu doğru mu, eğer öyleyse neden? Sadece bağlı mıyım -O2?

Gcc'nin ilk günlerinde (2.8 vb.) Ve egcs zamanında ve redhat 2.96-O3 bazen oldukça buggy idi. Ancak bu on yıldan uzun bir süre önce ve -O3 diğer optimizasyon seviyelerinden çok farklı değil (buggyness'te).

Bununla birlikte, dil (ler) in kurallarına ve özellikle köşe vakalarına daha sıkı güvenmesi nedeniyle, insanların tanımlanmamış davranışa güvendiği vakaları ortaya çıkarma eğilimindedir.

Kişisel bir not olarak, yıllardır -O3 ile finansal sektörde üretim yazılımı kullanıyorum ve -O2 kullansaydım orada olmayacak bir hatayla karşılaşmadım.

Yoğun talep üzerine, burada bir ek:

-O3 ve özellikle -funroll-loop gibi ek bayraklar (-O3 tarafından etkinleştirilmez) bazen daha fazla makine kodu oluşturulmasına neden olabilir. Belirli koşullar altında (örneğin, son derece küçük L1 komut önbelleğine sahip bir CPU'da) bu, örneğin artık L1I'ye uymayan bazı iç döngülerin tüm kodlarından dolayı yavaşlamaya neden olabilir. Genellikle gcc çok fazla kod üretmemek için oldukça uğraşır, ancak genellikle genel durumu optimize ettiğinden, bu olabilir. Özellikle buna eğilimli seçenekler (loop unrolling gibi) normalde -O3'e dahil edilmez ve buna uygun olarak işaretlenir. Bu nedenle, hızlı kod oluşturmak için -O3 kullanmak genellikle uygun olduğunda (örneğin bir profil oluşturucu L1I'nin kaçırdığını gösterdiğinde) -O2 veya -Os'a (kod boyutu için optimize etmeye çalışır) düşmek için iyi bir fikirdir.

Eğer optimizasyonu uç noktalara taşımak istiyorsanız, - gcc'de bazı optimizasyonlarla ilişkili maliyetleri artırabilirsiniz. Ek olarak, gcc'nin artık yalnızca bu işlevler için optimizasyon ayarlarını kontrol eden işlevlere öznitelik koyma yeteneğine sahip olduğunu unutmayın, bu nedenle bir işlevde -O3 ile ilgili bir sorununuz olduğunu fark ettiğinizde (veya yalnızca bu işlev için özel bayraklar denemek istiyorsanız), tüm dosyayı, hatta tüm projeyi O2 ile derlemenize gerek yoktur.

otoh -Ofast kullanırken dikkatli olunması gerektiği anlaşılıyor:

-Ofast tüm -O3 optimizasyonlarını mümkün kılar. Ayrıca tüm standart uyumlu programlar için geçerli olmayan optimizasyonları etkinleştirir.

bu da -O3'ün tamamen standartlara uygun olması gerektiği sonucuna varmamı sağlıyor.

Biraz damalı deneyimimde, -O3tüm bir programa başvurmak neredeyse her zaman daha yavaş (göreceli olarak -O2) yapar, çünkü programı artık talimat önbelleğine sığmayan agresif döngü açma ve satır açma özelliğini açar . Daha büyük programlar için, bu -O2göreceli olarak da geçerli olabilir -Os!

Amaçlanan kullanım deseni -O3, programınızın profilini oluşturduktan sonra, bu agresif hıza yönelik boşluklardan gerçekten yararlanan kritik iç döngüler içeren küçük bir avuç dolusu dosyaya manuel olarak uygulamanızdır. GCC'nin daha yeni sürümlerinde, (IIUC) -O3optimizasyonları sıcak işlevlere seçici olarak uygulayabilen ve bu işlemi etkili bir şekilde otomatikleştirebilen profil kılavuzlu bir optimizasyon modu vardır .

-O3 seçeneği, '-O2' ve '-O1' alt düzeylerinin tüm optimizasyonlarına ek olarak, fonksiyon satır içi gibi daha pahalı optimizasyonları da açar. '-O3' optimizasyon seviyesi, ortaya çıkan yürütülebilir dosyanın hızını artırabilir, ancak boyutunu da artırabilir. Bu optimizasyonların uygun olmadığı bazı durumlarda, bu seçenek aslında bir programı yavaşlatabilir.

Evet, O3 rahatsızlık verici. Derleyici geliştiriciyim ve kendi yazılımımı oluştururken O3 üreten buggy SIMD montaj talimatlarının neden olduğu net ve belirgin gcc hataları tespit ettim. Gördüğüm kadarıyla, çoğu üretim yazılımı O2 ile birlikte geliyor, bu da O3'ün wrt testi ve hata düzeltmelerine daha az dikkat edeceği anlamına geliyor.

Şöyle düşünün: O3, O2'nin üzerine daha fazla dönüşüm ekler ve bu da O1'in üzerine daha fazla dönüşüm ekler. İstatistiksel olarak konuşursak, daha fazla dönüşüm daha fazla hata anlamına gelir. Bu herhangi bir derleyici için geçerlidir.

Son zamanlarda optimizasyon ile ilgili bir sorun yaşadım g++. Sorun, kayıtların (komut ve veri için) bir bellek adresiyle temsil edildiği bir PCI kartla ilgiliydi. Sürücüm, fiziksel adresi uygulama içindeki bir işaretçiyle eşleştirdi ve çağrılan işleme verdi.

unsigned int * pciMemory;
askDriverForMapping( & pciMemory );
...
pciMemory[ 0 ] = someCommandIdx;
pciMemory[ 0 ] = someCommandLength;
for ( int i = 0; i < sizeof( someCommand ); i++ )
    pciMemory[ 0 ] = someCommand[ i ];

Kart beklendiği gibi davranmadı. Ben montaj görünce derleyici yalnızca yazdım anlaşılmaktadır someCommand[ the last ]içinepciMemory tüm önceki yazar atlayarak.

Sonuç olarak: optimizasyon ile doğru ve dikkatli olun.