What is difference between sjlj vs dwarf vs seh?

Question

I can't find enough information to decide which compiler should I use to compile my project. There are several programs on different computers simulating a process. On Linux, I'm using GCC. Everything is great. I can optimize code, it compiles fast and uses not-so-much memory.

I do my own benchmark with MSVC and GCC compilers. Later one produces slightly faster binaries (for each subarchitecture). Though compile time is much more than MSVC.

So I decided to use MinGW. But can't find any explanation about exception handling methods and their implementations in MinGW. I can use different distributions for different operating systems and architectures.

Considerations:

• Compile time and memory are not important for my usage. Only important thing is runtime optimization. I need my programs to be fast enough. A slow compiler is acceptable.
• OS: Microsoft Windows XP / 7 / 8 / Linux
• Architecture: Intel Core i7 / Core2 / and a very old i686 running XP :P

Solution 1

There's a short overview at MinGW-w64 Wiki:

Why doesn't mingw-w64 gcc support Dwarf-2 Exception Handling?

The Dwarf-2 EH implementation for Windows is not designed at all to work under 64-bit Windows applications. In win32 mode, the exception unwind handler cannot propagate through non-dw2 aware code, this means that any exception going through any non-dw2 aware "foreign frames" code will fail, including Windows system DLLs and DLLs built with Visual Studio. Dwarf-2 unwinding code in gcc inspects the x86 unwinding assembly and is unable to proceed without other dwarf-2 unwind information.

The SetJump LongJump method of exception handling works for most cases on both win32 and win64, except for general protection faults. Structured exception handling support in gcc is being developed to overcome the weaknesses of dw2 and sjlj. On win64, the unwind-information are placed in xdata-section and there is the .pdata (function descriptor table) instead of the stack. For win32, the chain of handlers are on stack and need to be saved/restored by real executed code.

GCC GNU about Exception Handling:

GCC supports two methods for exception handling (EH):

• DWARF-2 (DW2) EH, which requires the use of DWARF-2 (or DWARF-3) debugging information. DW-2 EH can cause executables to be slightly bloated because large call stack unwinding tables have to be included in th executables.
• A method based on setjmp/longjmp (SJLJ). SJLJ-based EH is much slower than DW2 EH (penalising even normal execution when no exceptions are thrown), but can work across code that has not been compiled with GCC or that does not have call-stack unwinding information.

[...]

Structured Exception Handling (SEH)

Windows uses its own exception handling mechanism known as Structured Exception Handling (SEH). [...] Unfortunately, GCC does not support SEH yet. [...]

See also:

• Exception handling models of GCC
• C++ Exception Handling for IA-64
• EH newbies howto

Solution 2

SJLJ (setjmp/longjmp): – available for 32 bit and 64 bit – not “zero-cost”: even if an exception isn’t thrown, it incurs a minor performance penalty (~15% in exception heavy code) – allows exceptions to traverse through e.g. windows callbacks

DWARF (DW2, dwarf-2) – available for 32 bit only – no permanent runtime overhead – needs whole call stack to be dwarf-enabled, which means exceptions cannot be thrown over e.g. Windows system DLLs.

SEH (zero overhead exception) – will be available for 64-bit GCC 4.8.

source: https://wiki.qt.io/MinGW-64-bit

Comments

[trojanfoe]

I'm surprised gcc produces faster code than MSVC; things must have changed in the last few years...

[sorush-r]

@trojanfoe I've been told so many times to use MSVC instead of MinGW. Everybody thinks msvc is faster! I tested MinGW 7.2 and MSVC 2010. with a simple cpu-burst program. On corei7 with -O3 -mtune=corei7 GCC is 45% faster than MSVC

[trojanfoe]

In my own experience, with a chess move generator (which used bitboards), both MSVC and Intel C++ were 10% quicker than gcc, but that was 2 year ago...

[Wolf]

@sorush-r just to be sure what "45% faster" means: 1.45 times as fast as MSVC?

[sorush-r]

@Wolf In that time 45% faster meant 45% less time to execute for me. If I remember correctly, execution time of our molecular geometry modelling software was 134s (gcc) and 194s (msvc) for a specific test. Nevertheless now I consider my method of measurement to be incorrect and insufficient (:

[Wolf]

@sorush-r I see, you calculated (194-134)/134 which is near 45%, thanks.

[namezero]

I think this will depend on the workload and what specific optimizations will/can be applied by a compiler under the circumstances. I had one example where a gruesome boost::spirit grammar ran very quickly on MSVC but the gcc's executable performance was less than stellar. That was a few years ago.

[Admin]

Sorry, source link is added.

[sorush-r]

Thanks for the links. I'm going to use DW2 for 32bit and SEH for 64. SEH is available in mingwbuilds (4.8). Should I wait for stable release of 4.8 or it's ok? It compiles here. I'm currently making dependencies of my project using 4.8 with SEH. No problems yet...

[sorush-r]

All dependencies (including Boost library, OpenSSL, ICU, freeGLUT) compiled but Qt end up with lots of internal compiler errors. I think I'll wait for stable release of 4.8

[Admin]

Did you use binaries of qt or did you compile by your own?

[sorush-r]

@woreos I use my own Qt build. I found that there was no problem with neither Qt nor GCC 4.8. It was my half-burned RAM! 1 Now everything works fine

[rustyx]

So now in 2016 we can put this question to rest and simply always use SEH.

[sohnryang]

@RustyX Only if your target is x86_64

[bsguru]

So Dwarf for x86?