Re: Oozing poison
On 01/28/12 05:18 PM, Scott Lurndal wrote:
Ian Collins<ian-news@hotmail.com> writes:
On 01/28/12 10:26 AM, Scott Lurndal wrote:
Ian Collins<ian-news@hotmail.com> writes:
On 01/28/12 09:29 AM, Scott Lurndal wrote:
I tried substituting a 'new uint8[xx}' call to replace a malloc with a try
catch block for bad_alloc. I then disassembled the code. One instruction
(to test the return value of the malloc) turned into:
How comes one version has multiple calls to new and the other one call
to malloc?
What was the original source?
uint8 cmd = iocb->get_op_var2();
buf = (uint8 *)malloc(bufsize);
if (buf == NULL) {
iocb->set_rd(IOT_WITH_EXCEPTIONS, RD1_OCS_MPU_PARITY);
return false;
}
switch (cmd) {
vs.
uint8 cmd = iocb->get_op_var2();
try {
buf = new uint8[bufsize];
} catch (std::exception e) {
never catch exceptions by value, always catch by const reference to
avoid slicing.
Good to know, I guess. Since I intend to keep the malloc and forgo
the try/catch clause, the point is however moot.
But it is a typical novice error that leads to false assumptions
regarding exception performance.
iocb->set_rd(IOT_WITH_EXCEPTIONS, RD1_OCS_MPU_PARITY);
return false;
}
switch (cmd) {
There is only one call to operator new (at 732a), the source code
is intermixed with the assembler by the 'objdump' utility and it replicated the source
line in multiple places.
This is fairly atypical use of exceptions, mixing exceptions and return
codes. It is more common to catch the exception at a higher call. This
simplifies the source and machine code (fewer conditional branches).
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.
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).
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.
} catch (std::exception x) {
73a0: 48 89 e7 mov %rsp,%rdi
73a3: e8 30 e1 ff ff callq 54d8
<std::exception::~exception()@plt>
73a8: e8 7b dd ff ff callq 5128<__cxa_end_catch@plt>
73ad: 0f 1f 00 nopl (%rax)
73b0: e9 41 01 00 00 jmpq 74f6
<c_uniline_dlp::echo(c_iocb*)+0x208>
73b5: 48 89 c5 mov %rax,%rbp
73b8: 48 89 e7 mov %rsp,%rdi
73bb: e8 18 e1 ff ff callq 54d8
<std::exception::~exception()@plt>
73c0: e8 63 dd ff ff callq 5128<__cxa_end_catch@plt>
73c5: 48 89 ef mov %rbp,%rdi
73c8: e8 3b de ff ff callq 5208<_Unwind_Resume@plt>
return false;
}
hardly bloat! Now if the exception is caught higher up the call chain
(with f() being a void function), there would be less, rather than more
code.
40 bytes. more than half a cache line each occurance (and you really should
count the exception object constructor/destructors too). In some cases, it really matters.
No I shouldn't.
It only occurred in your code because you caught by valve. No exception
object is created unless one is thrown. I also quoted more code than I
should (because of the catch by value). Change your code to catch by
const reference and you will see. For example, a bare bones example
with gcc:
bool f( X* iocb ){
try {
uint8_t* buf = new uint8_t[bufsize];
return true;
}
catch (const std::exception& e) {
return false;
}
}
compiles to (removing some labels for brevity):
pushl %ebp
movl %esp, %ebp
subl $24, %esp
movl $42, (%esp)
call _Znaj
movl $1, %eax
leave
ret
..L6:
subl $1, %edx
je .L4
movl %eax, (%esp)
call _Unwind_Resume
..L4:
movl %eax, (%esp)
call __cxa_begin_catch
call __cxa_end_catch
xorl %eax, %eax
leave
ret
And placing the catch higher in the call chain is not possible (at least not without
adding a large number of conditionals and carrying a great deal of state in
some derived exception class to the catch).
The state has to be carried somewhere... If it is only required in the
case of an error, the exception is the logical place for it.
--
Ian Collins