From: Roy S. <roy...@ic...> - 2008-12-11 20:39:03
|
While explaining the reference counting base class to Paul the other day, it struck me: why is this configure option independent of compilation mode? It's basically only used for debugging. Instead of just enabled or disabled, would it make more sense to add a third (and new default) option, that enables reference counting for dbg and devel modes but disables it for opt/prof? --- Roy |
From: Derek G. <fri...@gm...> - 2008-12-11 20:40:47
|
On Dec 11, 2008, at 1:38 PM, Roy Stogner wrote: > Instead of > just enabled or disabled, would it make more sense to add a third (and > new default) option, that enables reference counting for dbg and devel > modes but disables it for opt/prof? Yes... as soon as possible. Derek |
From: Benjamin K. <ben...@na...> - 2008-12-11 22:35:26
|
>> Instead of >> just enabled or disabled, would it make more sense to add a third (and >> new default) option, that enables reference counting for dbg and devel >> modes but disables it for opt/prof? > > Yes... as soon as possible. (lets hope this gets out before my battery dies.) The answer is no, it is not worth removing in optmized mode for non-threaded applications. Look at the reference counter - in debug mode it tracks references on a per-object basis using rtti and is expensive. In devel- and opt- modes, the reference counter is just a global int which gets ++ and --'ed, independent of object type. This is only a gross count - it lets you know if you created more objects than were destroyed, and in that case warns you to recompile in debug mode and find the error (in the LibMeshInit descructor). I think it should stay, at least without threading. -Ben |
From: Roy S. <roy...@ic...> - 2008-12-11 22:39:13
|
Benjamin Kirk wrote: >>> Instead of >>> just enabled or disabled, would it make more sense to add a third (and >>> new default) option, that enables reference counting for dbg and devel >>> modes but disables it for opt/prof? >> Yes... as soon as possible. > > (lets hope this gets out before my battery dies.) > > The answer is no, it is not worth removing in optmized mode for non-threaded > applications. > > Look at the reference counter - in debug mode it tracks references on a > per-object basis using rtti and is expensive. > > In devel- and opt- modes, the reference counter is just a global int which > gets ++ and --'ed, independent of object type. > > This is only a gross count - it lets you know if you created more objects > than were destroyed, and in that case warns you to recompile in debug mode > and find the error (in the LibMeshInit descructor). > > I think it should stay, at least without threading. I'm persuaded. --- Roy |
From: John P. <jwp...@gm...> - 2008-12-11 21:11:18
|
On Thu, Dec 11, 2008 at 2:38 PM, Roy Stogner <roy...@ic...> wrote: > > While explaining the reference counting base class to Paul the other > day, it struck me: why is this configure option independent of > compilation mode? It's basically only used for debugging. Instead of > just enabled or disabled, would it make more sense to add a third (and > new default) option, that enables reference counting for dbg and devel > modes but disables it for opt/prof? Is this a performance issue? Not every class is reference counted, and it's not like a reference-counted pointer which requires a lot of bookkeeping and junk to make sure all the counts are up-to-date. I don't object to turning it off during opt, just wondering if there was a big slowdown for your code. -- John |
From: Roy S. <roy...@ic...> - 2008-12-11 21:15:09
|
John Peterson wrote: > On Thu, Dec 11, 2008 at 2:38 PM, Roy Stogner <roy...@ic...> wrote: >> While explaining the reference counting base class to Paul the other >> day, it struck me: why is this configure option independent of >> compilation mode? It's basically only used for debugging. Instead of >> just enabled or disabled, would it make more sense to add a third (and >> new default) option, that enables reference counting for dbg and devel >> modes but disables it for opt/prof? > > Is this a performance issue? Not every class is reference counted, > and it's not like a reference-counted pointer which requires a lot of > bookkeeping and junk to make sure all the counts are up-to-date. I > don't object to turning it off during opt, just wondering if there was > a big slowdown for your code. No perceptible slowdown that I've noticed; it just struck me as a "debugging" sort of feature that we were using even when not debugging. I'd like to hear from Derek, though; I wasn't expecting an answer of "ASAP"! --- Roy |
From: Derek G. <fri...@gm...> - 2008-12-11 21:27:41
|
lol... the reason I said ASAP is that I always forget to turn it on.... and having it done automatically for debug/devel runs would help. As my applications stand right now.... I don't properly destroy _lots_ of reference counted objects... I'd like that to change in the future and one way to get some visibility would be to get a nag message every time I run in debug/devel modes ;-) I would rather it not be on by default for opt mode. Opt should be opt... as in... it should have everything not necessary for calculation turned off. People can still configure it to be on in opt mode... but by default I expect opt to be no nonsense. Derek On Dec 11, 2008, at 2:15 PM, Roy Stogner wrote: > John Peterson wrote: >> On Thu, Dec 11, 2008 at 2:38 PM, Roy Stogner <roy...@ic... >> > wrote: >>> While explaining the reference counting base class to Paul the other >>> day, it struck me: why is this configure option independent of >>> compilation mode? It's basically only used for debugging. >>> Instead of >>> just enabled or disabled, would it make more sense to add a third >>> (and >>> new default) option, that enables reference counting for dbg and >>> devel >>> modes but disables it for opt/prof? >> >> Is this a performance issue? Not every class is reference counted, >> and it's not like a reference-counted pointer which requires a lot of >> bookkeeping and junk to make sure all the counts are up-to-date. I >> don't object to turning it off during opt, just wondering if there >> was >> a big slowdown for your code. > > No perceptible slowdown that I've noticed; it just struck me as a > "debugging" sort of feature that we were using even when not > debugging. > I'd like to hear from Derek, though; I wasn't expecting an answer of > "ASAP"! > --- > Roy > > ------------------------------------------------------------------------------ > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, > Nevada. > The future of the web can't happen without you. Join us at MIX09 to > help > pave the way to the Next Web now. Learn more and register at > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel |