Re: How do you exception in your daily C++ programming? - test.cpp (0/1)
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.
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.
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.
My test code is attached to this post.
I'm afraid it's been stripped. At least, I don't see any attachment.
Mine is at http://gist.github.com/181071 and
http://gist.github.com/181060
My test results are at
http://cpp-next.com/wp-content/uploads/2009/09/eh-speed-g++.pdf
Several interesting things seem to be revealed there:
1. As noted earlier, unwinding is 25x slower than returning.
2. Adding empty exception specifications seems to help when the
functions in question can be inlined. Once the functions are
out-of-line, it mostly hurts. I don't expect to see the hurt on MSVC
because they (non-conformingly but perhaps wisely) ignore the runtime
semantics of exception specifications.
3. Neither disabling EH nor adding a catch block seems to have any
effect on speed unless an exception is thrown
It's Windows centric using the CPU performance counters. The timing
code may have to modified for Unix/Linux.
Right back atcha, vicey-versa.
I'm timing only the return path, not the function calls
themselves.
Not sure whether there's any way for me to do that. How do you manage
it?
No compiler I know of has a throw
that is as fast as normal function returns - but in a good
implementation they should be fairly close.
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 only way there is no additional overhead at
all is if the code contains no try blocks.
Try blocks aren't in principle any different from objects on the stack
with nontrivial dtors: both set up an action that needs to be performed
when an exception leaves the following scope.
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.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]