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
support!)
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 existed...
-Ben
On Oct 26, 2012, at 6:31 PM, "Lei Shi"
<stonesz...@gmail.com<mailto:stonesz...@gmail.com>> 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
<royst...@ices.utexas.edu<mailto:royst...@ices.utexas.edu>> wrote:
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.
---
Roy
[https://app.yesware.com/t/d1fcbaa1b12e0f6b1beef0b50d5ebbd873d1b8f9/1f16b46240a5a722bd9c1a049334259c/spacer.gif][http://app.yesware.com/t/d1fcbaa1b12e0f6b1beef0b50d5ebbd873d1b8f9/1f16b46240a5a722bd9c1a049334259c/spacer.gif]
------------------------------------------------------------------------------
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.
http://windows8center.sourceforge.net/
join-generation-app-and-make-money-coding-fast/
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net<mailto:Libmesh-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
------------------------------------------------------------------------------
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.
http://windows8center.sourceforge.net/
join-generation-app-and-make-money-coding-fast/
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
![https://app.yesware.com/t/d1fcbaa1b12e0f6b1beef0b50d5ebbd873d1b8f9/1f16b46240a5a722bd9c1a049334259c/spacer.gif][http://app.yesware.com/t/d1fcbaa1b12e0f6b1beef0b50d5ebbd873d1b8f9/1f16b46240a5a722bd9c1a049334259c/spacer.gif](https://app.yesware.com/t/d1fcbaa1b12e0f6b1beef0b50d5ebbd873d1b8f9/1f16b46240a5a722bd9c1a049334259c/spacer.gif][http://app.yesware.com/t/d1fcbaa1b12e0f6b1beef0b50d5ebbd873d1b8f9/1f16b46240a5a722bd9c1a049334259c/spacer.gif){kind=link}