Re: Oozing poison
Ian Collins <ian-news@hotmail.com> writes:
On 01/28/12 05:18 PM, Scott Lurndal wrote:
However, in this case (modeling a physical device), the best determination
of how to present the failure can be made as close to the cause of the
exception as possible. I would think that for most applications that
can actually recover from an error (as opposed to just catching std::exception
at the top level, printing a message, and exiting), keeping the recovery action
as close to the code that actually failed makes recovery much simpler.
It may well be, but the catch and the throw my still be several calls
away. Using nested small functions is much cleaner with exceptions than
with return codes. In your example you return the state in the object
passed. An exception based design may well pass the state in an
application specific exception.
Which will have additional overhead to allocate, construct,
destroy and deallocate the application class derived from std::exception, nicht wahr?
I think you would find that "small nested functions" is exactly what is
used, and in this case, the object passed doesn't necessary _return_ the state
passed so much as provide a channel for returning the state to the final
receipient.
Now in the core processor simulation code sigsetjmp/siglongjmp are used to reset
the simulated processor to the start of the instruction processing loop when
an exception occurs executing an instruction (an address error, invalid instruction,
etc). These could possibly be converted to exceptions, but I'm quite sure that
the performance would be worse and the RAS characteristics of the application
wouldn't change appreciably.
I remember reading Tom Cargill's article on exceptions back when they were
introduced to the language - I think many of his points still apply - exceptions
are not a universal panacea and careful analysis of all codepaths need be done
to prevent memory leaks or access to deallocated data when exceptions are being
thrown. The same caveats, of course, apply to setjmp/longjmp as well, but I
don't need to allocate an exception object (just set one of 10 bits in a member
field of the current 'this' when the longjmp is issued; the jmp_buf also a member
of the current object).
The catch is also the reason for all the extra code, constructing and
destructing a temporary std::exception object. The actual exception
handling part of the code is this bit:
Yet creating and destroying a temporary std::exception object also counts in
terms of both extra cycles and code footprint. Both of which impact
performance (generally negatively).
Only if the exceptional condition occurs. The normal path of execution
will not be impacted (and will be cleaner and faster than the error
checking case).
I haven't seen this in practice, but then my sole exposure to C++ code
has been in the Operating Systems/Microkernel/Hypervisor area none of which
used exceptions (most of which predated exceptions :-), aside from one
application at a major internet certification authority, which also predated
exceptions.
And indeed, some simple performance testing of code running under the simulation
(a 15,000 line BPL compile), shows that when I try exceptions in one of the common
allocation paths, the performance of the BPL compile drops from 17,177 records compiled
per minute to 16,585 records compiled per minute - an almost 4% performance degredation;
this is actually worse than I expected for a single conversion from malloc/init to
new/constructor with try/catch - I'll need to dig into this further.
If you are mixing exceptions and return codes, you aren't really making
a fair comparison. It is very likely you could improve the performance
in other ways, such as a specialised allocator. If your application was
designed to use exceptions throughout, I bet you would see a performance
improvement.
Unfortunately, this is a 60,000+ SLOC application and making such a change
wouldn't be useful - there are only a half dozen or so dynamic allocations
in the entire application, and I'm working on eliminating most of those
(or moving them to the application initialization phase).
Let me be clear, I never actually took an exception in the test I described above;
the sole difference was changing the
buf = malloc(XXX); if (buf == NULL) { YYY}
test to
try {buf = new uint8[XXX];} catch (std::exception& e) { YYY }
(and of course, the corresponding 'free()' <-> 'delete []' changes).
The exception was never thrown during the test (but the test function was called
about 500,000 times while the processor code simulated 43,000,000 mainframe instructions)
over a wall-time duration of about 25 seconds.
Since there is a hard (and relatively small) limit on the number of objects of
the type in the test that can be allocated during a run (basically one per simulated
processor and a couple of extras), I plan on overloading operator new for the
object and using a startup-allocated pool of objects to handle object allocation. This
will eliminate both checks.
Similar mechanisms will be used for all other run-time (vs. initialization time)
allocations.
scott