From: Roy S. <roy...@ic...> - 2011-06-02 20:45:50
|
On Thu, 2 Jun 2011, Vijay S. Mahadevan wrote: >> Make vec() const? > > Yes ! I had a patch for this on my local version of libmesh but > eventually made all the calls to use const_cast so that I dont have > any remaining patches. But making it const will remove some ugliness. Unless anyone else objects, send me a patch for that and mat() and we'll make them const. > I always felt that mutable and const_cast were hacky to get around > something that was not supposed to be done in the first place. Yeah, but often "what's not supposed to be done" is "using a non-const-correct third-party dependency", and as I pointed out there don't seem to be a whole lot of options for const-correct third-party linear algebra libraries. > But sometimes designing a library does need some internal hacks to > make it efficient I guess. My 2 cents. Actually, what's wrong with "const" is that the compiler *can't* use it for efficiency. Since const_cast exists, the compiler can't assume that even a const local variable is truly unchanging so long as a pointer or reference to it gets passed to another function; this precludes a number of optimizations. And since a compiler can always tell whether a function's *own* code changes a variable, in that case const is redundant for optimization purposes. So basically const has nothing to do with efficiency (except hypothetically in cases where you can write a const version of a method that's more efficient than the non-const version, and where you trust that class's users to treat const_cast as forbidden). It can't be used to help the compiler, just to help the programmer catch bugs. But it's decent at that, so I still use it religiously. I wish there was some sort of const_until_out_of_scope_no_kidding keyword that the compiler was allowed to make use of too, though. And a pony, and a this_is_a_single_valued_function_not_a_procedure_with_side_effects keyword, while I'm making wishes. There's probably a hundred for loops in libMesh that could be hand-optimized by moving a const object's const method out of the end condition test and caching its result, either because the method isn't inlined (and so the compiler can't guarantee it'll give the same result each time) or because the loop body calls non-inlined functions (and so the compiler can't guarantee that those functions don't futz with an alias to the object). --- Roy |
From: Vijay S. M. <vi...@gm...> - 2011-06-02 21:21:39
|
> Unless anyone else objects, send me a patch for that and mat() and > we'll make them const. Will do tonight. > Yeah, but often "what's not supposed to be done" is "using a > non-const-correct third-party dependency", and as I pointed out there > don't seem to be a whole lot of options for const-correct third-party > linear algebra libraries. Interestingly, I've noticed that all the FEM libraries use "const" liberally while not many of the lower level linear algebra packages do. This might be because the linear algebra routines are usually in fortran or c. Except for Trilinos, I can't think of anything of an extensive LA library in c++. Flens comes to mind but it is not parallel or robust as Petsc or Trilinos and it uses BLAS internally.. Anyway, I do agree. > Actually, what's wrong with "const" is that the compiler *can't* use > it for efficiency. Since const_cast exists, the compiler can't assume > that even a const local variable is truly unchanging so long as a > pointer or reference to it gets passed to another function; this > precludes a number of optimizations. And since a compiler can always > tell whether a function's *own* code changes a variable, in that case > const is redundant for optimization purposes. Ah yes. My mistake. Wrong choice of words. It is efficient from the user (of a library) perspective since there is a certain guarantee that the object wont change state. But "mutable" makes this dodgy. On the other hand, you do need "mutable" sometimes to optimize internally for caching etc on a const object. So it is a hard bargain. I do remember a certain case about read-only objects in a local scope i.e., say const MyClass *m = new MyClass(), where the compiler knows for sure that the object does not change and can load it in a newer generation of the heap or a non-writable portion of the memory. This of course still depends on the compiler and the options provided. I cant find any reference related to this on google though. So maybe I am wrong.. Yes the compiler in general can't optimize as you say but it does bug me every now and then because "const" is like a virus. Once you make a key parameter const, it avalanches quickly into several modifications in your design and suddenly, there is const everywhere ;) Vijay On Thu, Jun 2, 2011 at 3:45 PM, Roy Stogner <roy...@ic...> wrote: > > On Thu, 2 Jun 2011, Vijay S. Mahadevan wrote: > >>> Make vec() const? >> >> Yes ! I had a patch for this on my local version of libmesh but >> eventually made all the calls to use const_cast so that I dont have >> any remaining patches. But making it const will remove some ugliness. > > Unless anyone else objects, send me a patch for that and mat() and > we'll make them const. > >> I always felt that mutable and const_cast were hacky to get around >> something that was not supposed to be done in the first place. > > Yeah, but often "what's not supposed to be done" is "using a > non-const-correct third-party dependency", and as I pointed out there > don't seem to be a whole lot of options for const-correct third-party > linear algebra libraries. > >> But sometimes designing a library does need some internal hacks to >> make it efficient I guess. My 2 cents. > > Actually, what's wrong with "const" is that the compiler *can't* use > it for efficiency. Since const_cast exists, the compiler can't assume > that even a const local variable is truly unchanging so long as a > pointer or reference to it gets passed to another function; this > precludes a number of optimizations. And since a compiler can always > tell whether a function's *own* code changes a variable, in that case > const is redundant for optimization purposes. > > So basically const has nothing to do with efficiency (except > hypothetically in cases where you can write a const version of a > method that's more efficient than the non-const version, and where you > trust that class's users to treat const_cast as forbidden). It can't > be used to help the compiler, just to help the programmer catch bugs. > > But it's decent at that, so I still use it religiously. I wish there > was some sort of const_until_out_of_scope_no_kidding keyword that the > compiler was allowed to make use of too, though. And a pony, and a > this_is_a_single_valued_function_not_a_procedure_with_side_effects > keyword, while I'm making wishes. There's probably a hundred for > loops in libMesh that could be hand-optimized by moving a const > object's const method out of the end condition test and caching its > result, either because the method isn't inlined (and so the compiler > can't guarantee it'll give the same result each time) or because the > loop body calls non-inlined functions (and so the compiler can't > guarantee that those functions don't futz with an alias to the > object). > --- > Roy > |
From: Vijay S. M. <vi...@gm...> - 2011-06-04 04:32:48
Attachments:
const_raw_petsc.patch
|
Sorry for the delay because I had to update to the latest version without breaking my own code. Here's the patch. It was a lot easier/simpler than I remembered. And I could still compile/link/run the examples. Hopefully, it wont break anything in the user code. Vijay On Thu, Jun 2, 2011 at 3:45 PM, Roy Stogner <roy...@ic...> wrote: > > On Thu, 2 Jun 2011, Vijay S. Mahadevan wrote: > >>> Make vec() const? >> >> Yes ! I had a patch for this on my local version of libmesh but >> eventually made all the calls to use const_cast so that I dont have >> any remaining patches. But making it const will remove some ugliness. > > Unless anyone else objects, send me a patch for that and mat() and > we'll make them const. > >> I always felt that mutable and const_cast were hacky to get around >> something that was not supposed to be done in the first place. > > Yeah, but often "what's not supposed to be done" is "using a > non-const-correct third-party dependency", and as I pointed out there > don't seem to be a whole lot of options for const-correct third-party > linear algebra libraries. > >> But sometimes designing a library does need some internal hacks to >> make it efficient I guess. My 2 cents. > > Actually, what's wrong with "const" is that the compiler *can't* use > it for efficiency. Since const_cast exists, the compiler can't assume > that even a const local variable is truly unchanging so long as a > pointer or reference to it gets passed to another function; this > precludes a number of optimizations. And since a compiler can always > tell whether a function's *own* code changes a variable, in that case > const is redundant for optimization purposes. > > So basically const has nothing to do with efficiency (except > hypothetically in cases where you can write a const version of a > method that's more efficient than the non-const version, and where you > trust that class's users to treat const_cast as forbidden). It can't > be used to help the compiler, just to help the programmer catch bugs. > > But it's decent at that, so I still use it religiously. I wish there > was some sort of const_until_out_of_scope_no_kidding keyword that the > compiler was allowed to make use of too, though. And a pony, and a > this_is_a_single_valued_function_not_a_procedure_with_side_effects > keyword, while I'm making wishes. There's probably a hundred for > loops in libMesh that could be hand-optimized by moving a const > object's const method out of the end condition test and caching its > result, either because the method isn't inlined (and so the compiler > can't guarantee it'll give the same result each time) or because the > loop body calls non-inlined functions (and so the compiler can't > guarantee that those functions don't futz with an alias to the > object). > --- > Roy > |