165
votes

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
2
I'm surprised gcc produces faster code than MSVC; things must have changed in the last few years... - trojanfoe
@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 - sorush-r
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... - trojanfoe
@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 (: - sorush-r
@sorush-r I see, you calculated (194-134)/134 which is near 45%, thanks. - Wolf

2 Answers

119
votes

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:

90
votes

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