Sjlj vs dwarf vs seh arasındaki fark nedir?

152

Projemi derlemek için hangi derleyiciyi kullanmam gerektiğine karar vermek için yeterli bilgi bulamıyorum. Bir işlemi simüle eden farklı bilgisayarlarda birkaç program vardır. Linux'ta GCC kullanıyorum. Her şey harika. Kodu optimize edebilirim, hızlı derler ve çok fazla bellek kullanmaz.

MSVC ve GCC derleyicileriyle kendi kıyaslamamı yapıyorum. Daha sonra biri biraz daha hızlı ikili dosyalar üretir (her alt mimari için). Derleme süresi MSVC'den çok daha fazladır.

Bu yüzden MinGW'yi kullanmaya karar verdim. Ancak istisna işleme yöntemleri ve MinGW'deki uygulamaları hakkında herhangi bir açıklama bulamıyorum. Farklı işletim sistemleri ve mimariler için farklı dağıtımlar kullanabilirim.

Hususlar:

  • Derleme zamanı ve bellek kullanımım için önemli değil. Tek önemli şey çalışma zamanı optimizasyonudur. Programlarımın yeterince hızlı olmasına ihtiyacım var. Yavaş bir derleyici kabul edilebilir.
  • İşletim Sistemi: Microsoft Windows XP / 7/8 / Linux
  • Mimari: Intel Core i7 / Core2 / ve XP: P çalıştıran çok eski bir i686
c++  compiler-construction  mingw  cpu-architecture  mingw-w64 
— üzüntü
kaynak
5
Gcc'nin MSVC'den daha hızlı kod üretmesine şaşırdım; son birkaç yılda işler değişmiş olmalı ...
— trojanfoe
19
@trojanfoe Birçok kez MinGW yerine MSVC kullanmam söylendi. Herkes msvc'nin daha hızlı olduğunu düşünüyor! MinGW 7.2 ve MSVC 2010'u basit bir cpu-burst programı ile test ettim. GCC'li corei7'de MSVC'den -O3 -mtune=corei7% 45 daha hızlı
— sorush-r
5
Kendi deneyimlerime göre, bir satranç hamle oluşturucu (bitboard kullanan) ile, hem MSVC hem de Intel C ++ gcc'den% 10 daha hızlıydı, ancak bu 2 yıl önceydi ...
— trojanfoe
2
@Wolf O zamanlar% 45 daha hızlı, benim için% 45 daha az zaman harcamak anlamına geliyordu. Doğru hatırlıyorsam, moleküler geometri modelleme yazılımımızın uygulama süresi belirli bir test için 134s (gcc) ve 194s (msvc) idi. Yine de şimdi ölçüm yöntemimin yanlış ve yetersiz olduğunu düşünüyorum (:
— sorush-r
3
@ sorush-r Görüyorum,% 45'e yakın olan (194-134) / 134'ü hesapladınız, teşekkürler.
— Wolf

Yanıtlar:

112

MinGW-w64 Wiki'de kısa bir genel bakış var :

Mingw-w64 gcc neden Dwarf-2 Exception Handling'i desteklemiyor?

Cüce-2 EH Windows için uygulama 64 bit Windows uygulamaları altında çalışmalarına hiç tasarlanmamıştır. Win32 modunda, özel durum çözme işleyicisi dw2 farkında olmayan kod aracılığıyla yayılamaz; bu, Windows sistem DLL'leri ve Visual Studio ile oluşturulan DLL'ler de dahil olmak üzere, dw2'nin farkında olmayan "yabancı çerçeveler" kodundan geçen herhangi bir istisnanın başarısız olacağı anlamına gelir. Gcc'deki Dwarf-2 çözme kodu x86 çözme düzeneğini inceler ve diğer cüce-2 çözme bilgileri olmadan ilerleyemez.

SetJump LongJump win32 ve Win64 hem çoğu durum için istisna işleme eser yöntem, genel koruma hataları için hariç. Gcc'deki yapılandırılmış istisna işleme desteği, dw2 ve sjlj'nin zayıflıklarının üstesinden gelmek için geliştirilmektedir. Win64'te çözme bilgileri xdata bölümüne yerleştirilir ve yığın yerine .pdata (işlev tanımlayıcı tablosu) bulunur. Win32 için, işleyiciler zinciri yığın halindedir ve gerçek yürütülen kodla kaydedilmesi / geri yüklenmesi gerekir.

İstisna İşleme hakkında GCC GNU :

GCC, istisna işleme (EH) için iki yöntemi destekler:

  • DWARF-2 (DW2) EH , DWARF-2 (veya DWARF-3) hata ayıklama bilgilerinin kullanılmasını gerektirir. DW-2 EH, yürütülebilir dosyalara büyük çağrı yığını çözme tablolarının dahil edilmesi gerektiğinden, yürütülebilir dosyaların biraz şişirilmesine neden olabilir.
  • Setjmp / longjmp (SJLJ) tabanlı bir yöntem . SJLJ tabanlı EH, DW2 EH'den çok daha yavaştır (hiçbir istisna atılmadığında normal yürütmeyi bile cezalandırır), ancak GCC ile derlenmemiş veya çağrı yığını çözme bilgisine sahip olmayan kodlarda çalışabilir.

[...]

Yapılandırılmış İstisna İşleme (SEH)

Windows, Yapılandırılmış Özel Durum İşleme (SEH) olarak bilinen kendi özel durum işleme mekanizmasını kullanır. [...] Maalesef GCC henüz SEH'yi desteklemiyor. [...]

Ayrıca bakınız:

— Ollo
kaynak
7
Bağlantılar için teşekkürler. 32bit için DW2 ve 64 için SEH kullanacağım. SEH mingwbuilds'de mevcuttur (4.8). 4.8'in kararlı sürümünü beklemeli miyim yoksa sorun yok mu? Burada derleniyor. Şu anda SEH ile 4.8 kullanarak projemin bağımlılıklarını yapıyorum. Henüz sorun yok ...
— sorush-r
2
Tüm bağımlılıklar (Boost kitaplığı, OpenSSL, ICU, freeGLUT dahil) derlendi, ancak Qt birçok dahili derleyici hatasıyla sonuçlanır. Sanırım
— 4.8'in
Qt'nin ikili dosyalarını mı kullandınız yoksa kendi başınıza mı derlediniz?
4
@woreos Kendi Qt yapımı kullanıyorum. Ne Qt ne de GCC 4.8 ile ilgili bir sorun olmadığını buldum. Yarı yanmış RAM'imdi! 1 Şimdi her şey yolunda
— gidiyor
84

SJLJ (setjmp / longjmp): - 32 bit ve 64 bit için mevcuttur - "sıfır maliyet" değildir: bir istisna atılmasa bile, küçük bir performans cezasına neden olur (istisna ağır kodda ~% 15) - istisnalara izin verir örneğin Windows geri aramalarında gezinmek için

DWARF (DW2, dwarf-2) - yalnızca 32 bit için mevcuttur - kalıcı çalışma zamanı ek yükü yoktur - tüm çağrı yığınının cüce özellikli olması gerekir, bu da istisnaların örneğin Windows sistem DLL'leri üzerinden atılamayacağı anlamına gelir.

SEH (sıfır ek yük istisnası) - 64 bit GCC 4.8 için mevcut olacaktır.

kaynak: http://qt-project.org/wiki/MinGW-64-bit

2
Üzgünüz, kaynak bağlantısı eklendi.
2
Cevabınız için teşekkürler;)
— sorush-r
14
Şimdi 2016'da bu soruyu bir kenara bırakıp basitçe SEH'yi kullanabiliriz.
— rustyx
6
@RustyX Yalnızca hedefiniz x86_64 ise
— sohnryang
Yani x86 için Cüce?
— banguru
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.