Actually, It is not important to me. I'm trying to learn object oriented
design and meta-programming skills for scientific computing from libMesh.
Right now, I only use a very thin layer of encapsulation in my code.
Coupling is very tight there. I read some source code of libMesh and ask
several questions to you guys. Roy suggested me to do some tests. I think
the best way to learn a lib is to work on it. So this is the story. May be
I can work on some other stuffs. Thanks.
On Sat, Oct 27, 2012 at 7:01 AM, Kirk, Benjamin (JSC-EG311) <
> Lei, could you explain why this particular part is important to you? As
> Roy pointed out, for implicit apps this never shows up as a bottleneck, and
> for JFNK work I think Derek agrees there are other hotspots? Why not
> address those if performance is an issue?
> I don't want to discourage the change, but there are other deficiencies in
> libMesh where development could have a much bigger impact. (I swear one of
> these days I'll get to that blocked matrix
> Because finite element objects tend to have a lot of lifetime per
> computation (they get reused for a lot of elements) the allocation issue is
> not really a driver. The dereferencing is, but as profiling reveals it is
> not that big of a deal.
> To answer your original question, we use a vector<vector> mostly because
> this section of code dates back to 2002, well before portable high
> performance expression templates were reliable. And based on our recent
> discussion you can see that the API is a trap once it is in place...
> Since the allocation and storage part is currently a non-issue, I wonder
> if the simplest path to reduce the dereferencing hit is to store an Eigen
> object along side the vector<vector>, deprecate the old API, and move to
> the (i,j) scheme directly? For the adventurous we could disable the
> backwards compatibility at configure time so only the Eigen storage
> On Oct 26, 2012, at 6:31 PM, "Lei Shi" <stoneszone@...> wrote:
> Sorry for the late.
> It seems that in order to provide backward compatible APIs, we need such
> kind of shim class. Roy, What is your final decision?
> Sincerely Yours,
> Lei Shi
> On Thu, Oct 25, 2012 at 1:21 PM, Roy Stogner <roystgnr@...:
>> On Thu, 25 Oct 2012, Boyce Griffith wrote:
>> Libraries like Eigen and Blitz++ use operator() for accessors rather
>>> than operator. How horrible would it be to go ahead and change to
>>> operator() when making this change to LibMeshNArray?
>> Hmmm... it would mean that we couldn't get away with starting with
>> just a typedef, we'd actually have to build a basic shim class right
>> from the start, and it would be much more of a pain in the neck for
>> user codes to upgrade.
>> On the other hand, if we did want to keep operator support around
>> indefinitely and we end up with a target class that doesn't support
>> it, that would mean we'd have to keep a shim class around
>> indefinitely... *and* we'd make it much less convenient to use a
>> different-semantic operator from the target class, e.g. the Blitz++
>> component accessor.
>> More opinions would be welcome; I'm not even sure what I'd prefer yet.
> WINDOWS 8 is here.
> Millions of people. Your app in 30 days.
> Visit The Windows 8 Center at Sourceforge for all your go to resources.
> Libmesh-devel mailing list