Re: How do you exception in your daily C++ programming? - test.cpp (0/1)
On Fri, 4 Sep 2009 17:31:34 CST, David Abrahams <dave@boostpro.com>
wrote:
on Fri Sep 04 2009, George Neuner <gneuner2-AT-comcast.net> wrote:
On Thu, 3 Sep 2009 16:28:34 CST, Mathias Gaunard <loufoque@gmail.com>
wrote:
On 3 sep, 16:26, George Neuner <gneun...@comcast.net> wrote:
If you want high performance from exceptions, you need to catch them
as close as possible to the throw point.
I don't think that's very sensible advice.
Just catch the exceptions where it makes sense and where you have
enough information to do something relevant. Catching too early
defeats the point of exceptions.
I agree ... but the cost of stack cleanup on an exception path is
orders of magnitude greater than the cost of the very same cleanup on
a normal function return path. That makes throwing out of deeply
nested calls prohibitive for high performance code
Only if you are expecting to get lots of exceptions. But you shouldn't
be using exceptions in that situation anyway; exceptions should be
relatively rare.
and possibly deadly for real time code.
Well now, that's true. Possibly deadly. Test and measure to find out.
The whole discussion is meaningless unless you're considering high
performance code ... at minimum soft real time.
We are only talking about, at most, milliseconds ... but that might
matter to a real time program on a slower processor - not every
program will be run on 3GHz 64-bit quad-cores.
But regardless, catching close to the throw point doesn't help you at
all if you don't throw. Otherwise, you pay about a 25x penalty per
stack frame (on my g++ implementation) to unwind. If you can't afford a
25x slowdown on the EH paths in the rare instance an exception does
occur, you've got a problem with EH.
Compiled for maximum speed, on my 3Ghz dual Pentium 4 Windows box, the
difference between the timing of the normal return path and the
exception return path for a 2 level nested call is 80..200x depending
on whether there are local dtor objects (the no objects case is
actually worse as there more hidden exception overhead).
Unless you're targeting 64-bit windows, you're not testing a
particularly good EH implementation.
??? 64-bit Windows uses the same SEH implementation as 32-bit.
C++ EH is slightly faster than Windows SEH. In VS2008 you can choose
which to use. If you mean the 64-bit compiler has a better C++ EH
implementation, then I have to plead ignorance ... I'll have to look
into it.
I don't have a Unix or Linux box handy to test GCC natively. I get
roughly similar timings using GCC in cygwin. GCC is slightly better
with no local objects and VS2008 is slightly better with local
objects.
Like MS's Win32, Cygwin also uses a poor EH implementation based on
setjmp/longjmp.
VS2008 uses a table based implementation unless you select SEH
handling. Cygwin is an older version of G++ (3.4.5) so that - I don't
have a 4.4 to test so that will definitely make a difference.
The recommended implementation of exceptions certainly does not
provide a cheap throw. On the other hand, if no exceptions happen,
there is no overhead.
This isn't true. Even with the table address-range implementation,
there is additional work done by the preamble of any function that
contains a try block.
I don't think so. What additional work do you think needs to be done in
that case? And, what's a preamble ;-)?
The preamble is the code that sets up the call frame.
Table based EH implementations need no runtime setup to catch
synchronous C++ exceptions, but if you use OS structured exceptions
(in Windows or Linux) then there is extra EH information placed in the
stack frame.
That paragraph turned out a little more pedantic than I intended it to
be. I started out saying "In general, this isn't true ..." and the
generality got lost in editing.
The costs that are harder to avoid in a address-range implementation have
to do with keeping cleanup information around to do cleanup when
nonthrowing code isn't detectable as such by the compiler:
int a = 3;
try
{
f(); // some non-inline function that happens not to throw
}
catch(...)
{
do_something_with(a);
}
If f has been declared
void f();
instead of
void f() throw();
the compiler has no way of knowing that it doesn't need to keep the
value of a around for use in the catch block. This effect usually takes
the form of what's known as "register pressure." As far as I can tell,
register pressure can only happen with try/catch, though, and not object
destructors, since destructors have to run whether or not an exception
is thrown.
Mostly it translates as memory traffic because register values have to
be flushed to memory ahead of the try block so they can be restored
later if necessary. It may also mean double buffering the values that
are used in the try block or that are passed as reference parameters
to functions in the try block.
George
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]