On Wed, 24 Oct 2012, Lei Shi wrote:
There are lot of vector<vector> stuffs in the FE and FEMap classes. Why do we
use this instead of a well defined matrix class. I think there are several
drawbacks to use vector<vector> as a matrix. There is a discussion on this at
stackexchange. http://scicomp.stackexchange.com/questions/3159/is-it-a-good-idea-to-use-vectorvectordouble-to-form-a-matrix-class-for-high/3182#3182
Several drawbacks people mentioned
1. redundant data structures (multiple rows points)
2. scattered memory.
3. bad cache efficiency
These are all correct, although IIRC the inefficiencies don't show up
in any profiled libMesh apps I've seen.
Is there any reason to use vector<vector>? Thanks.
Inertia. It probably got used initially because it's simplest, and
then later on because changing it would be a lot of work and an
API-incompatible change. On the other hand, if you take a look at our
current vector<vector<> > indexing ordering you'll see that it's
backwards for typical SIMD optimizations, so if we'd used a proper
matrix class we'd still have made the same (much more important)
mistake there and had to change it anyway, too.
We would like to switch to a proper matrix class. Even if your 3
points above aren't noticeable performance problems, the SIMD issue
might be, and we might as well fix everything at once if we have to
break API compatibility anyway. But, nobody's had the time lately,
and to do it right we'd need to template or even shim around the
implementation class so that we could benchmark with multiple options
before settling on a default. If you're volunteering, we'd be happy
to help answer any questions along the way!
Looks like Paul beat me to answering your 2nd question.
---
Roy
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel