sjlj vs dwarf vs seh의 차이점은 무엇입니까?

147

프로젝트를 컴파일하는 데 사용해야하는 컴파일러를 결정하기에 충분한 정보를 찾을 수 없습니다. 다른 컴퓨터에는 프로세스를 시뮬레이션하는 여러 프로그램이 있습니다. Linux에서는 GCC를 사용하고 있습니다. 모든것이 좋아. 코드를 최적화 할 수 있고, 빠르게 컴파일되고 그다지 많은 메모리를 사용하지 않습니다.

MSVC 및 GCC 컴파일러를 사용하여 자체 벤치 마크를 수행합니다. 나중에 하나는 약간 빠른 바이너리를 생성합니다 (각 서브 아키텍처마다). 컴파일 시간은 MSVC 이상입니다.

그래서 MinGW를 사용하기로 결정했습니다. 그러나 MinGW에서 예외 처리 방법 및 구현에 대한 설명을 찾을 수 없습니다. 운영 체제 및 아키텍처마다 다른 배포판을 사용할 수 있습니다.

고려 사항 :

컴파일 시간과 메모리는 사용에 중요하지 않습니다. 중요한 것은 런타임 최적화입니다. 프로그램이 충분히 빨라야합니다. 느린 컴파일러가 허용됩니다.
운영체제 : Microsoft Windows XP / 7 / 8 / Linux
아키텍처 : Intel Core i7 / Core2 / XP : P를 실행하는 매우 오래된 i686

— 수두
소스

gcc가 MSVC보다 더 빠른 코드를 생성한다는 것에 놀랐습니다. 지난 몇 년 동안 상황이 바뀌었을 것입니다 ...

— trojanfoe

@trojanfoe MinGW 대신 MSVC를 사용하라는 말을 여러 번 들었습니다. 모두 msvc가 더 빠르다고 생각합니다! 간단한 CPU 버스트 프로그램으로 MinGW 7.2 및 MSVC 2010을 테스트했습니다. -O3 -mtune=corei7GCC가 포함 된 corei7에서 MSVC보다 45 % 빠릅니다

— sorush-r

내 경험상, 비트 보드를 사용한 체스 이동 생성기를 사용하면 MSVC와 Intel C ++ 모두 gcc보다 10 % 빠르지 만 2 년 전 ...

— trojanfoe

@Wolf 그 시간에 45 % 빠르다는 것은 45 % 단축 된 시간이었습니다. 올바르게 기억한다면 분자 기하 모델링 소프트웨어의 실행 시간은 특정 테스트에서 134 초 (gcc)와 194 초 (msvc)였습니다. 그럼에도 불구하고 지금 나는 나의 측정 방법이 부정확하고 불충분하다고 생각한다 (:

— sorush-r

@ sorush-r 알다시피, 당신은 45 %에 가까운 (194-134) / 134를 계산했습니다. 감사합니다.

— Wolf

답변:

109

MinGW-w64 Wiki 에는 간단한 개요가 있습니다 .

왜 mingw-w64 gcc가 Dwarf-2 예외 처리를 지원하지 않습니까?

드워프-2 EH의 Windows 용 구현은 64 비트 Windows 응용 프로그램에서 작업에 전혀 설계되지 않았습니다. win32 모드에서 예외 해제 해제 핸들러는 비 dw2 인식 코드를 통해 전파 될 수 없습니다. 이는 Visual Studio로 빌드 된 Windows 시스템 DLL 및 DLL을 포함하여 비 dw2 인식 "외부 프레임"코드를 통과하는 예외가 실패 함을 의미합니다. gcc의 드워프 -2 풀림 코드는 x86 풀기 어셈블리를 검사하여 다른 드워프 -2 풀기 정보가 없으면 진행할 수 없습니다.

예외 처리 의 SetJump LongJump 방법은 일반적인 보호 오류를 제외하고 대부분의 경우 win32 및 win64 모두에서 작동합니다. gcc의 구조적 예외 처리 지원은 dw2 및 sjlj의 약점을 극복하기 위해 개발되고 있습니다. win64에서 해제 정보는 xdata-section에 있으며 스택 대신 .pdata (함수 설명자 테이블)가 있습니다. win32의 경우 처리기 체인이 스택에 있으며 실제 실행 코드로 저장 / 복원해야합니다.

예외 처리 에 관한 GCC GNU :

GCC는 예외 처리 (EH)를위한 두 가지 방법을 지원합니다.

DWARF-2 (DW2) EH . DWARF-2 (또는 DWARF-3) 디버깅 정보를 사용해야합니다. DW-2 EH는 큰 호출 스택 해제 테이블이 실행 파일에 포함되어야하기 때문에 실행 파일이 약간 부풀어 질 수 있습니다.

setjmp / longjmp (SJLJ) 기반의 메소드입니다 . SJLJ 기반 EH는 DW2 EH보다 속도가 훨씬 느리지 만 (예외가 발생하지 않으면 일반 실행에도 불이익을 주지만) GCC로 컴파일되지 않았거나 콜 스택 해제 정보가없는 코드에서 작동 할 수 있습니다.

[...]

구조적 예외 처리 (SEH)

Windows는 구조적 예외 처리 (SEH)라는 자체 예외 처리 메커니즘을 사용합니다. [...] 불행히도 GCC는 아직 SEH를 지원하지 않습니다. [...]

또한보십시오:

— 올로
소스

링크 주셔서 감사합니다. 32 비트 용 DW2와 64 용 SEH를 사용하겠습니다. SEH는 mingwbuilds (4.8)에서 사용할 수 있습니다. 4.8의 안정적인 릴리스를 기다려야합니까, 아니면 괜찮습니까? 여기에 컴파일됩니다. 현재 SEH에서 4.8을 사용하여 프로젝트를 종속성으로 만들고 있습니다. 아직 문제 없습니다 ...

— sorush-r

모든 의존성 (부스트 라이브러리, OpenSSL, ICU, freeGLUT 포함)을 컴파일했지만 Qt는 많은 내부 컴파일러 오류로 끝납니다. 나는 4.8의 안정적인 릴리스를 기다릴 것이라고 생각한다

— sorush-r

qt 바이너리를 사용 했습니까, 아니면 직접 컴파일하셨습니까?

@woreos 나는 내 자신의 Qt 빌드를 사용합니다. Qt 나 GCC 4.8 모두 문제가 없음을 발견했습니다. 반쯤 구운 RAM이었습니다! 1 이제 모든 것이 잘 작동합니다

— sorush-r

SJLJ (setjmp / longjmp) : – 32 비트 및 64 비트에 사용 가능 –“제로 비용”아님 : 예외가 발생하지 않더라도 약간의 성능 저하가 발생합니다 (예외 무거운 코드에서 ~ 15 %) – 예외 허용 예를 들어 창 콜백을 통과하는 것

DWARF (DW2, dwarf-2) – 32 비트 만 가능 – 영구 런타임 오버 헤드 없음 – 전체 호출 스택이 드워프 가능해야합니다. 즉, Windows 시스템 DLL과 같은 예외를 처리 할 수 없습니다.

SEH (제로 오버 헤드 예외) – 64 비트 GCC 4.8에서 사용할 수 있습니다.

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

죄송합니다. 소스 링크가 추가되었습니다.

답변 주셔서 감사합니다;)

— sorush-r

이제 2016 년 에이 질문을 쉬게하고 항상 SEH를 사용할 수 있습니다.

— rustyx

@RustyX 대상은 x86_64의 경우에만

— sohnryang

x86의 난쟁이?

— banguru