Performance hit using exception handling using aCC

[zzfreddybb]

We are using HP aCC compiler on a HP Itanium box ( 11.23)

We are having some severe performance hits using exception
handling ( try/catch ) scenarios.

The online aCC documentation says:
HP aC++ exception handling has no significant performance impact at
compile-time or run-time.

We have not found this to be the case at all.

We are using the caliper measurement tool and it seems to indicate
that the application is spending 50% or more of it cpu cycles
in the unwind library.

We are not using any special arguments to aCC as exception handling
is enabled by default.

I can provide a simple short example to illustrate the case if needed
or requested.

Any comments, suggestions, ideas would be mucn appreciated.
Thank you,

Fred B.

 

[Lionel B]

<cross-posts removed>

We are using HP aCC compiler on a HP Itanium box ( 11.23)

We are having some severe performance hits using exception
handling ( try/catch ) scenarios.

The online aCC documentation says:
HP aC++ exception handling has no significant performance impact at
compile-time or run-time.

We have not found this to be the case at all.

We are using the caliper measurement tool and it seems to indicate
that the application is spending 50% or more of it cpu cycles
in the unwind library.

This seems to imply that the performance hit you refer to is incurred
during exception processing - i.e. when exceptions are actually thrown.
So is your code actually throwing a lot of exceptions? If so, then the
"performance hit" sounds entirely reasonable; there will inevitably be
an overhead associated with stack unwinding, etc. I'm sure your
compiler documentation would not claim that *processing* exceptions
incurs no performance penalty.

FWIW, I found using gcc on a Win32 system that - despite claims to the
contrary by the compiler documentation - just *enabling* exception
handling incurred a performance (speed) hit of roughly 20% under heavy
floating-point number-crunching, *even when no exception handling
(try/catch blocks) was present in the code* ...
Regards,

 

[Peter Koch Larsen]

We are using HP aCC compiler on a HP Itanium box ( 11.23)

We are having some severe performance hits using exception
handling ( try/catch ) scenarios.

The online aCC documentation says:
HP aC++ exception handling has no significant performance impact at
compile-time or run-time.

We have not found this to be the case at all.

We are using the caliper measurement tool and it seems to indicate
that the application is spending 50% or more of it cpu cycles
in the unwind library.

We are not using any special arguments to aCC as exception handling
is enabled by default.

I can provide a simple short example to illustrate the case if needed
or requested.

Any comments, suggestions, ideas would be mucn appreciated.
Thank you,

Fred B.

I do not know your compiler, but my guess is lots of exceptions get thrown.
In that case your program is likely to pay for that. Exceptions should be
the exceptional, and if you do use them for other purposes, it is not unfair
that you pay for the performance hit. Restructure your code so that
exceptions only are thrown in exceptional cases.
Apart from that, you should post to a newsgroup dedicated to your compiler.

/Peter

 

[Peter Koch Larsen]

<cross-posts removed>

zzfreddybb wrote:
[snip]


FWIW, I found using gcc on a Win32 system that - despite claims to the
contrary by the compiler documentation - just *enabling* exception
handling incurred a performance (speed) hit of roughly 20% under heavy
floating-point number-crunching, *even when no exception handling
(try/catch blocks) was present in the code* ...

This is the case under win32 where i believe exception handling is
implemented at it is in Visual C++. There, code is injected to take care of
the stack unwinding. Under Linux, g++ will use another approach with no
effects on runtime when exceptions are not thrown.

/Peter

 

[Dennis Handly]

zzfreddybb ([email protected]) wrote:
: HP aC++ exception handling has no significant performance impact at
: compile-time or run-time.
: We have not found this to be the case at all.

As Peter says, this means you have no "significant performance impact", if
you don't use throw.

: Any comments, suggestions, ideas would be much appreciated.
: Fred B.

A future version (around May 2005 or so) of the unwind library
(Unwind Express) will be 10 X faster in trivial cases.
Also, are you using threads?

From: "Peter Koch Larsen" <[email protected]>
In that case your program is likely to pay for that. Exceptions should be
the exceptional, and if you do use them for other purposes, it is not unfair
that you pay for the performance hit.

Apart from that, you should post to a newsgroup dedicated to your compiler.

That would be the CXX-DEV mailing list. See:
http://h21007.www2.hp.com/dspp/comm/comm_Community_Home_IDX/1,1273,,00.html