I always cache a reference to the shape function vectors I need outside the element loop so in this case I can't imagine there is a difference between an inline and virtual function call.
-Ben On May 10, 2012, at 5:37 PM, "Roy Stogner" <royst...@ices.utexas.edu> wrote: > > Paul Bauman has an application that's motivating him to put > vector-valued FE capabilities into libMesh, and I've got a > shame-this-wasnt-done-years-ago that's motivating me to help, so we're > hashing out design ideas now. > > Two design decisions that've come up, submitted for general commentary: > > > 1.: For vector-valued data, it would be good to return shape values as > a vector-of-vector-of-Gradients instead of > vector-of-vector-of-Numbers, and shape derivatives would be a > vector-of-vector-of-Tensors. (we'll probably postpone second > derivative support and add a Rank3Tensor class or some such for it). > > All agreed? The alternative (returning > vector-of-vector-of-vector-of-Numbers, etc) would be much uglier for > user code. > > > The catch with this is that the current FEBase already stores > vector-of-vector-of-Numbers. And returns it, directly, via inline > get_phi(). > > > So, 2.: Do we create FEAbstract, which doesn't include *phi* data or > get_*phi* methods, then derive FEBase and FEVectorBase from it? Or do > we just add get_vec_*phi* methods (and vec_*phi data) to FEBase? > > With the latter option, we'd have a bunch of redundant (albeit empty) > vectors in every FEBase, and trying to access scalar data from a > vector element type or vice-versa would be a runtime error (or > possibly only an assert), not very type safe. > > With the former option, we'd end up having to turn get_*phi* from > inline functions into virtual functions. This is what we're leaning > towards. The cost of a virtual function is relatively trivial when > amortized. I benchmark a few percent overhead when compared to even > dead simple bilinear-fe linear residual-type loops, a few thousandths > of a percent overhead when compared to biquadratic slightly nonlinear > jacobian-type loops. > > The cost of preventing crazy optimizations can be huge: in the inlined > case icpc originally detected that my fakey benchmark couldn't be > changing phi in-between get_phi calls, reordered my loops to make the > element loop the inner loop, then vectorized and combined my equations > to chop out 90% of the FLOPs... but even a slight added code > complication (a do-nothing but non-const method called on the fake FE > object) took things back to normal; I can't imagine anything similar > affecting a real code where we call FE::reinit on every element. > --- > Roy > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Libmesh-devel mailing list > Libmesh-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/libmesh-devel ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
