Jaka jest różnica między Sjlj vs Dwarf vs SEH?

147

Nie mogę znaleźć wystarczających informacji, aby zdecydować, którego kompilatora powinienem użyć do skompilowania projektu. Na różnych komputerach znajduje się kilka programów symulujących proces. W systemie Linux używam GCC. Wszystko w porządku. Potrafię zoptymalizować kod, szybko się kompiluje i zużywa mało pamięci.

Robię własny benchmark z kompilatorami MSVC i GCC. Później tworzy się nieco szybsze pliki binarne (dla każdej podarchitektury). Chociaż czas kompilacji to znacznie więcej niż MSVC.

Postanowiłem więc użyć MinGW. Ale nie mogę znaleźć żadnego wyjaśnienia na temat metod obsługi wyjątków i ich implementacji w MinGW. Potrafię używać różnych dystrybucji dla różnych systemów operacyjnych i architektur.

Uwagi:

Czas kompilacji i pamięć nie są ważne dla mojego użytkowania. Jedyną ważną rzeczą jest optymalizacja czasu działania. Chcę, aby moje programy były wystarczająco szybkie. Dopuszczalny jest powolny kompilator.
System operacyjny: Microsoft Windows XP / 7/8 / Linux
Architektura: Intel Core i7 / Core2 / i bardzo stary i686 z systemem XP: P

— sorush-r
źródło

Jestem zaskoczony, że gcc tworzy szybszy kod niż MSVC; coś musiało się zmienić w ciągu ostatnich kilku lat ...

— trojanfoe

@trojanfoe Wiele razy mówiono mi, żebym używał MSVC zamiast MinGW. Wszyscy myślą, że msvc jest szybszy! Przetestowałem MinGW 7.2 i MSVC 2010. za pomocą prostego programu cpu-burst. Na corei7 z -O3 -mtune=corei7GCC jest 45% szybszy niż MSVC

— sorush-r

Z własnego doświadczenia wynika, że z generatorem ruchów szachowych (który wykorzystywał tablice bitowe), zarówno MSVC, jak i Intel C ++ były o 10% szybsze niż gcc, ale to było 2 lata temu ...

— trojanfoe

@Wolf W tym czasie 45% szybciej oznaczało dla mnie 45% mniej czasu na wykonanie. Jeśli dobrze pamiętam, czas wykonania naszego oprogramowania do modelowania geometrii molekularnej wyniósł 134s (gcc) i 194s (msvc) dla konkretnego testu. Niemniej jednak teraz uważam, że moja metoda pomiaru jest błędna i niewystarczająca (:

— sorush-r

@ sorush-r Widzę, obliczyłeś (194-134) / 134, czyli blisko 45%, dzięki.

— Wolf

Odpowiedzi:

109

Krótki przegląd na MinGW-w64 Wiki :

Dlaczego gcc mingw-w64 nie obsługuje obsługi wyjątków Dwarf-2?

-2 Dwarf EH implementacja dla systemu Windows nie jest przeznaczony do pracy w ogóle pod 64-bitowych aplikacji Windows. W trybie win32 program obsługi wycofywania wyjątku nie może być propagowany przez kod nieobsługujący dw2, co oznacza, że każdy wyjątek przechodzący przez dowolny kod „obcych ramek” nieobsługujący dw2 zakończy się niepowodzeniem, w tym biblioteki DLL systemu Windows i biblioteki DLL utworzone w programie Visual Studio. Kod rozwijania dwarf-2 w gcc sprawdza zestaw rozwijania x86 i nie może kontynuować bez innych informacji o rozwijaniu dwarf-2.

SetJump LongJump metoda prac Obsługa wyjątków w większości przypadków zarówno na win32 i Win64, oprócz ogólnych błędów ochrony. Strukturalna obsługa obsługi wyjątków w gcc jest rozwijana w celu przezwyciężenia słabości dw2 i sjlj. W win64 informacje o rozwijaniu są umieszczane w sekcji xdata, a zamiast stosu znajduje się .pdata (tablica deskryptorów funkcji). W przypadku win32 łańcuch programów obsługi znajduje się na stosie i musi zostać zapisany / przywrócony przez rzeczywiście wykonany kod.

GCC GNU o obsłudze wyjątków :

GCC obsługuje dwie metody obsługi wyjątków (EH):

DWARF-2 (DW2) EH , który wymaga użycia informacji debugowania DWARF-2 (lub DWARF-3). DW-2 EH może spowodować, że pliki wykonywalne będą nieco rozdęte, ponieważ duże tabele rozwijania stosu wywołań muszą być zawarte w plikach wykonywalnych.

Metoda oparta na setjmp / longjmp (SJLJ) . Oparty na SJLJ EH jest znacznie wolniejszy niż DW2 EH (penalizuje nawet normalne wykonanie, gdy nie są zgłaszane żadne wyjątki), ale może działać w kodzie, który nie został skompilowany za pomocą GCC lub który nie ma informacji o rozwijaniu stosu wywołań.

[…]

Strukturalna obsługa wyjątków (SEH)

System Windows używa własnego mechanizmu obsługi wyjątków znanego jako Structured Exception Handling (SEH). [...] Niestety, GCC nie obsługuje jeszcze SEH. […]

Zobacz też:

— ollo
źródło

Dzięki za linki. Mam zamiar używać DW2 dla 32-bitowych i SEH dla 64. SEH jest dostępny w mingwbuilds (4.8). Powinienem poczekać na stabilną wersję 4.8, czy jest ok? Kompiluje się tutaj. Obecnie tworzę zależności mojego projektu przy użyciu 4.8 z SEH. Żadnych problemów ...

— sorush-r

Wszystkie zależności (w tym biblioteka Boost, OpenSSL, ICU, freeGLUT) zostały skompilowane, ale Qt kończy się wieloma wewnętrznymi błędami kompilatora. Myślę, że poczekam na stabilne wydanie 4.8

— sorush-r

Używałeś plików binarnych qt, czy też skompilowałeś je samodzielnie?

@woreos Używam własnej kompilacji Qt. Okazało się, że nie ma problemu ani z Qt, ani z GCC 4.8. To była moja w połowie spalona pamięć RAM! 1 Teraz wszystko działa dobrze

— sorush-r

SJLJ (setjmp / longjmp): - dostępne dla wersji 32-bitowej i 64-bitowej - nie „zero-koszt”: nawet jeśli nie zostanie zgłoszony wyjątek, powoduje to niewielki spadek wydajności (~ 15% w przypadku ciężkiego kodu wyjątków) - zezwala na wyjątki do przechodzenia przez np. wywołania zwrotne systemu Windows

DWARF (DW2, dwarf-2) - dostępny tylko dla wersji 32-bitowej - bez stałego obciążenia środowiska uruchomieniowego - wymaga, aby cały stos wywołań był włączony, co oznacza, że wyjątki nie mogą być przerzucane na przykład przez biblioteki DLL systemu Windows.

SEH (wyjątek zerowego narzutu) - będzie dostępny dla 64-bitowego GCC 4.8.

źródło: http://qt-project.org/wiki/MinGW-64-bit

Przepraszamy, link do źródła został dodany.

Dzięki za odpowiedź;)

— sorush-r

Więc teraz, w 2016 roku, możemy odłożyć to pytanie i po prostu zawsze używać SEH.

— rustyx

@RustyX Tylko jeśli twoim celem jest x86_64

— sohnryang

Więc Dwarf na x86?

— banguru