Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #13621
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Newsgroups | comp.lang.c++ |
| Subject | Re: Oozing poison |
| Date | 2012-01-28 18:06 +1300 |
| Message-ID | <9ohe2qF8j0U9@mid.individual.net> (permalink) |
| References | (7 earlier) <ZODUq.107194$487.76393@news.usenetserver.com> <9oghusF8j0U4@mid.individual.net> <3EEUq.107196$487.32649@news.usenetserver.com> <9ogpsvF8j0U6@mid.individual.net> <qGKUq.152389$624.85025@news.usenetserver.com> |
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
Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Oozing poison AD <isquat@gmail.com> - 2012-01-10 04:35 -0800
Re: Oozing poison Leigh Johnston <leigh@i42.co.uk> - 2012-01-10 15:19 +0000
Re: Oozing poison AD <isquat@gmail.com> - 2012-01-11 00:43 -0800
Re: Oozing poison "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2012-01-11 10:01 +0100
Re: Oozing poison Ian Collins <ian-news@hotmail.com> - 2012-01-11 22:09 +1300
Re: Oozing poison AD <isquat@gmail.com> - 2012-01-11 01:42 -0800
Re: Oozing poison Leigh Johnston <leigh@i42.co.uk> - 2012-01-11 13:36 +0000
Re: Oozing poison John Bokma <john@castleamber.com> - 2012-01-11 10:08 -0600
Re: Oozing poison AD <isquat@gmail.com> - 2012-01-12 06:08 -0800
Re: Oozing poison Leigh Johnston <leigh@i42.co.uk> - 2012-01-12 14:13 +0000
Re: Oozing poison AD <isquat@gmail.com> - 2012-01-17 02:08 -0800
Re: Oozing poison Henrik Faber <hfaber@invalid.net> - 2012-01-17 12:50 +0100
Re: Oozing poison Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-13 02:18 -0800
Re: Oozing poison AD <isquat@gmail.com> - 2012-01-17 02:24 -0800
Re: Oozing poison Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-11 16:50 +0000
Re: Oozing poison AD <isquat@gmail.com> - 2012-01-12 06:04 -0800
Re: Oozing poison Victor Bazarov <v.bazarov@comcast.invalid> - 2012-01-12 10:13 -0500
Re: Oozing poison AD <isquat@gmail.com> - 2012-01-17 02:19 -0800
Re: Oozing poison Victor Bazarov <v.bazarov@comcast.invalid> - 2012-01-17 08:04 -0500
Re: Oozing poison Miles Bader <miles@gnu.org> - 2012-01-18 13:51 +0900
Re: Oozing poison AD <isquat@gmail.com> - 2012-01-21 04:40 -0800
Re: Oozing poison Quint Rankid <qbr567@gmail.com> - 2012-01-21 09:05 -0800
Re: Oozing poison Wil Evers <bouncer@dev.null> - 2012-01-21 18:52 +0000
Re: Oozing poison Quint Rankid <qbr567@gmail.com> - 2012-01-21 11:33 -0800
Re: Oozing poison AD <isquat@gmail.com> - 2012-01-25 02:23 -0800
Re: Oozing poison AD <isquat@gmail.com> - 2012-01-25 02:07 -0800
Re: Oozing poison Victor Bazarov <v.bazarov@comcast.invalid> - 2012-01-25 07:59 -0500
Re: Oozing poison Ian Collins <ian-news@hotmail.com> - 2012-01-26 07:54 +1300
Re: Oozing poison Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2012-01-21 22:43 -0500
Re: Oozing poison Ian Collins <ian-news@hotmail.com> - 2012-01-22 21:05 +1300
Re: Oozing poison Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2012-01-22 18:21 -0500
Re: Oozing poison Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-23 15:55 +0000
Re: Oozing poison gwowen <gwowen@gmail.com> - 2012-01-23 08:37 -0800
Re: Oozing poison Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2012-01-24 22:48 -0500
Re: Oozing poison Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-25 19:44 +0000
Re: Oozing poison Ian Collins <ian-news@hotmail.com> - 2012-01-26 08:56 +1300
Re: Oozing poison 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-25 23:04 -0800
Re: Oozing poison Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-26 03:24 -0800
Re: Oozing poison scott@slp53.sl.home (Scott Lurndal) - 2012-01-26 19:13 +0000
Re: Oozing poison Brian Drummond <brian@shapes.demon.co.uk> - 2012-01-27 00:12 +0000
Re: Oozing poison "MikeWhy" <boat042-nospam@yahoo.com> - 2012-01-26 22:44 -0600
Re: Oozing poison 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-28 14:25 -0800
Re: Oozing poison Robert Miles <milesrf@Usenet-News.net> - 2012-02-26 22:16 -0600
Re: Oozing poison "Gernot Frisch" <me@privacy.net> - 2012-01-24 18:21 +0100
Re: Oozing poison Victor Bazarov <v.bazarov@comcast.invalid> - 2012-01-24 12:41 -0500
Re: Oozing poison Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-26 03:25 -0800
Re: Oozing poison Rui Maciel <rui.maciel@gmail.com> - 2012-01-25 19:44 +0000
Re: Oozing poison Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-26 09:44 +0000
Re: Oozing poison Rui Maciel <rui.maciel@gmail.com> - 2012-01-26 10:36 +0000
Re: Oozing poison scott@slp53.sl.home (Scott Lurndal) - 2012-01-26 19:18 +0000
Re: Oozing poison Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-26 20:42 +0000
Re: Oozing poison Juha Nieminen <nospam@thanks.invalid> - 2012-01-26 16:30 +0000
Re: Oozing poison scott@slp53.sl.home (Scott Lurndal) - 2012-01-26 19:24 +0000
Re: Oozing poison Cholo Lennon <chololennon@hotmail.com> - 2012-01-26 17:13 -0300
Re: Oozing poison scott@slp53.sl.home (Scott Lurndal) - 2012-01-26 20:55 +0000
Re: Oozing poison Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-26 22:08 +0000
Re: Oozing poison scott@slp53.sl.home (Scott Lurndal) - 2012-01-27 00:32 +0000
Re: Oozing poison Dombo <dombo@disposable.invalid> - 2012-01-28 12:59 +0100
Re: Oozing poison Cholo Lennon <chololennon@hotmail.com> - 2012-01-27 18:28 -0300
Re: Oozing poison Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-29 18:02 +0000
Re: Oozing poison Ian Collins <ian-news@hotmail.com> - 2012-01-27 20:18 +1300
Re: Oozing poison Miles Bader <miles@gnu.org> - 2012-01-27 18:09 +0900
Re: Oozing poison scott@slp53.sl.home (Scott Lurndal) - 2012-01-27 20:29 +0000
Re: Oozing poison Ian Collins <ian-news@hotmail.com> - 2012-01-28 10:06 +1300
Re: Oozing poison scott@slp53.sl.home (Scott Lurndal) - 2012-01-27 21:26 +0000
Re: Oozing poison Ian Collins <ian-news@hotmail.com> - 2012-01-28 12:22 +1300
Re: Oozing poison scott@slp53.sl.home (Scott Lurndal) - 2012-01-28 04:18 +0000
Re: Oozing poison Miles Bader <miles@gnu.org> - 2012-01-28 13:44 +0900
Re: Oozing poison scott@slp53.sl.home (Scott Lurndal) - 2012-01-28 21:31 +0000
Re: Oozing poison Ian Collins <ian-news@hotmail.com> - 2012-01-29 11:32 +1300
Re: Oozing poison 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-28 14:55 -0800
Re: Oozing poison Ian Collins <ian-news@hotmail.com> - 2012-01-29 11:59 +1300
Re: Oozing poison scott@slp53.sl.home (Scott Lurndal) - 2012-01-30 17:08 +0000
Re: Oozing poison Ian Collins <ian-news@hotmail.com> - 2012-01-28 18:06 +1300
Re: Oozing poison scott@slp53.sl.home (Scott Lurndal) - 2012-01-28 22:49 +0000
Re: Oozing poison Ian Collins <ian-news@hotmail.com> - 2012-01-29 12:22 +1300
Re: Oozing poison scott@slp53.sl.home (Scott Lurndal) - 2012-01-27 20:16 +0000
Re: Oozing poison Ian Collins <ian-news@hotmail.com> - 2012-01-28 10:01 +1300
Re: Oozing poison Juha Nieminen <nospam@thanks.invalid> - 2012-01-28 16:00 +0000
Re: Oozing poison Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-10 21:42 +0000
Re: Oozing poison AD <isquat@gmail.com> - 2012-01-17 02:31 -0800
csiph-web