Kai Tietz <ktiet...@googlemail.com> writes:
>> "zero cost" here means that ordinary (non-exceptional) paths of
>> execution runs at the same speed than a executable with no exceptions
>> enabled. When an exception is thrown, things change: then SEH can be
>> faster than Dwarf2. But on most C++ programs the execution goes through
>> non-exceptional paths almost all the time, so I'll expect that an
>> application built with Dwarf2 will be a bit faster than the same built
>> with SEH.
>
> That is actually not true in general. SEH for x86 introduces
> instructions, which are executed. For x64 SEH is table-based and
> therefore no code is inserted. For x86 is SEH still faster then SjLj,
> but might be a bit slower then dw2, as long as no exception was
> handled. On the point that exception-handling happens, dw2 suddenly
> gets very ugly. At least the version present for x86. First, it gets
> slow ... yes, even slower as SjLj due additional probing and unwinding
> costs. These costs aren't present for SjLj, nor for SEH.
I was thinking on x86 all along and I don't know how SEH on x64 works.
Sadly, until a lot of time passes most Windows developers will have to
deal with x86 (and why care at all about x64 until then?) So SEH on x64
is irrelevant. Please note that I'm not diminishing the value of your
effort on x64.
[snip]
> Also are the patterns used to get prologue for
> dw2-unwinder all but complete, and show in some scenarios bugs, which
> makes it completely unusable. As it limits amount of usable
> function-prologue-code it implicit slow-down code.
Thanks for the info.
>> That's the reason why we C++ programmers with high performance
>> requirements see SLJL as something to avoid.
> Hmm, well, high-performance on Windows ... anyway ...
Yes, sure: "high performance" means that the application shall run as
fast as possible on the available hardware. It applies to Windows too
:-)
On this specific topic I can't switch from MSVC++ to g++ SJLJ because
the users would complain about the slowdown and it would condition my
coding practice for the worse ("if I use RAII here this method will be
6x slower".) And dw2 is risky, as you explained. So I'm forced to stick
to the crappy MSVC++ compiler.
[snip]
>> BTW, I thought that the problem of Dwarf2 with DLLs was fixed a long
>> time ago.
>
> In a bad way, and requires shared libgcc DLL to work proper. Nothing
> to be proud of.
That explains why my tests worked.
I was active on the MinGW mailing lists at the time when dw2 was
introduced. Lots of analysis effort went into resolving the problem with
DLLs and the non-dw2 frames. At the end the auxiliary DLL "solution" was
chosen for addressing the DLL problem, and the non-dw2 frame problem was
considered as unsolvable. I can assure you that no MinGW maintainer was
happy with the outcome.
------------------------------------------------------------------------------
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13.
http://pubads.g.doubleclick.net/gampad/clk?id=64545871&iu=/4140/ostg.clktrk
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
