Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Oozing poison

Reply
Thread Tools

Oozing poison

 
 
Ian Collins
Guest
Posts: n/a
 
      01-28-2012
On 01/29/12 10:31 AM, Scott Lurndal wrote:
> Miles Bader<(E-Mail Removed)> writes:
>> http://www.velocityreviews.com/forums/(E-Mail Removed) (Scott Lurndal) writes:
>>>> 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).

>>
>> Er, exceptions are intended to be _exceptional_.
>>
>> If some exception occurs so often that it has a measurable performance
>> impact, it probably shouldn't be an exception.

>
> The exception never occurs (i.e., I never run out of memory). It's the
> added code to handle the exception and it's effect on a (very) hot codepath
> that causes the 4% hit in performance. That is the only change in the
> codebase, and I ran the benchmark three times with each flavor (try/catch/new
> vs. malloc). I have to admit that I was surprised by the difference and I'm
> going to take a look at the actual codepaths and do some profiling to see why
> adding a try/catch clause has such a large effect, when the exception is never
> taken.


How about new (without the exceptions) compared to malloc? new is doing
more work than malloc, one reason I suggested a specialised allocator.

--
Ian Collins
 
Reply With Quote
 
 
 
 
88888 Dihedral
Guest
Posts: n/a
 
      01-28-2012
在 2012年1月29日星期日UTC+8上午6时32分57秒 ,Ian Collins写道:
> On 01/29/12 10:31 AM, Scott Lurndal wrote:
> > Miles Bader<(E-Mail Removed)> writes:
> >> (E-Mail Removed) (Scott Lurndal) writes:
> >>>> 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).
> >>
> >> Er, exceptions are intended to be _exceptional_.
> >>
> >> If some exception occurs so often that it has a measurable performance
> >> impact, it probably shouldn't be an exception.

> >
> > The exception never occurs (i.e., I never run out of memory). It's the
> > added code to handle the exception and it's effect on a (very) hot codepath
> > that causes the 4% hit in performance. That is the only change in the
> > codebase, and I ran the benchmark three times with each flavor (try/catch/new
> > vs. malloc). I have to admit that I was surprised by the difference and I'm
> > going to take a look at the actual codepaths and do some profiling to see why
> > adding a try/catch clause has such a large effect, when the exception is never
> > taken.

>
> How about new (without the exceptions) compared to malloc? new is doing
> more work than malloc, one reason I suggested a specialised allocator.
>
> --
> Ian Collins


Well, an object with some methods to generate new objects not to be garbagecollected very soon following the o stack push-pop mechnism of auto varibles are somewaht evil in C++ if the programmer does not think carefully and write codes to chain these methods in class B arbitrarily then there might be a definitely expoenti ally growth rate of the heap used by a lousy fatprogramming hog in some programs.
 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      01-28-2012
On 01/29/12 11:55 AM, 88888 Dihedral wrote:
> 在 2012年1月29日星期日UTC+8上午6时32分57秒 ,Ian Collins写道:
>> On 01/29/12 10:31 AM, Scott Lurndal wrote:
>>> Miles Bader<(E-Mail Removed)> writes:
>>>> (E-Mail Removed) (Scott Lurndal) writes:
>>>>>> 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).
>>>>
>>>> Er, exceptions are intended to be _exceptional_.
>>>>
>>>> If some exception occurs so often that it has a measurable performance
>>>> impact, it probably shouldn't be an exception.
>>>
>>> The exception never occurs (i.e., I never run out of memory). It's the
>>> added code to handle the exception and it's effect on a (very) hot codepath
>>> that causes the 4% hit in performance. That is the only change in the
>>> codebase, and I ran the benchmark three times with each flavor (try/catch/new
>>> vs. malloc). I have to admit that I was surprised by the difference and I'm
>>> going to take a look at the actual codepaths and do some profiling to see why
>>> adding a try/catch clause has such a large effect, when the exception is never
>>> taken.

>>
>> How about new (without the exceptions) compared to malloc? new is doing
>> more work than malloc, one reason I suggested a specialised allocator.

>
> Well, an object with some methods to generate new objects not to be garbage collected very soon following the o stack push-pop mechnism of auto varibles are somewaht evil in C++ if the programmer does not think carefully and write codes to chain these methods in class B arbitrarily then there might be a definitely expoenti ally growth rate of the heap used by a lousy fat programming hog in some programs.


Do what?

--
Ian Collins
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      01-28-2012
On 01/29/12 11:49 AM, Scott Lurndal wrote:
> Ian Collins<(E-Mail Removed)> 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?


Only in the exceptional circumstances where one is thrown. As I said,
the state has to be returned somewhere.

> 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.


By using exceptions, you are able to utilise the full power of the
language, such as RAII which out of band jumps preclude.

One point I have been trying to make is bolting exceptions onto an
existing design is seldom a good idea. Neither is having to take them
out, which was a situation I once found myself in! Error handling is a
fundamental part of a system's design and mixing paradigms invariably
ends in tears.

> 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.


This is true and the language provides us with the tools to achieve
this. Tools which cannot be used with out of band jumps!

> 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 cost of constructing an exception object are far outweighed by the
cost of throwing it *in the exceptional case*.

>>>> 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.


That's where our experiences diverge, I've been comparing the
performance of exceptions on various platforms for many years and I've
found exceptions are generally faster (always on the Unix and Linux
platforms I use). From my perspective, the exceptions vs error returns
argument was settled long ago.

> 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).


You have introduced two variables, exceptions and new. Try eliminating
both.

--
Ian Collins
 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      01-29-2012
On Fri, 2012-01-27, Cholo Lennon wrote:
> On 26/01/2012 19:08, Jorgen Grahn wrote:
>> Keep in mind, both of you, that the best way to deal with casting is
>> to avoid doing it! Or isolating it to a few places. C++ provides
>> better tools for that than C.
>>

>
> I agree, of course, but when you have to deal with legacy C or low level
> code casting appears (and I have to say that there is a lot of legacy C
> code)


Yes, and I think part of what I was trying to say was: When you have a
chance to rewrite such code, it pays to first check if you can
eliminate the cast in some other way (e.g. with a wrapper function
which does the casting) rather than replace the C-style cast with the
best C++ cast.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
Robert Miles
Guest
Posts: n/a
 
      02-27-2012
On 1/21/2012 6:40 AM, AD wrote:
> On Jan 18, 6:51 am, Miles Bader<(E-Mail Removed)> wrote:
>> AD<(E-Mail Removed)> writes:
>>>> So, you're not coding in C++, and you come to a C++ community hangout to
>>>> complain about C++ being difficult to comprehend, and you expect what,
>>>> sympathy?<shrug>

>>
>>> I'm not coding in C++ ANYMORE
>>> I could not possibly see how it can be used to write robust code

>>
>> You expect us to trust your judgement?
>>
>> [I've found C++ _much_ easier to write robust code in compared to C.
>> It is clearly no proof against incompetent coders (nothing is), but it
>> does offer some really good tools to help competent ones...]
>>

> Well, objective-c (and it's inherent to all c based languages, unless
> you start ripping out pointers, etc) is prone to allowing a single fly-
> idiot
> poisoning the whole barrel, and java like languages
> were designed precisely to keep idiots at bay, but c++ seems to be
> especially
> susceptible to providing morons with tools to automate
> writing some crap code.


Looks like you've been fired from a programming management job
for incompetence in choosing which programmers you hired, but
weren't fired fast enough to keep you from becoming familiar
with those incompetent programmers.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
poison ivy W.Henry Computer Support 34 07-14-2006 02:00 AM
Poison pics show up online: Another MS problem. John Computer Security 5 10-09-2004 01:15 PM
Re: Poison pics show up online: Another MS problem. John E. Carty Computer Security 0 10-04-2004 12:48 AM



Advertisments