I hate to even ask, but Roy what is eigen's license? We could easily package it 
and become very, very dependent, but given recent discussions...

-Ben



On Oct 24, 2012, at 4:00 PM, "Lei Shi" 
<stonesz...@gmail.com<mailto:stonesz...@gmail.com>> wrote:

Hi Roy,

Yes, SIMD is critical to enhancing performance. However, as you mentioned that, 
based on the profiling results of several libmesh examples, there is no big 
efficiency issue on FEMap and FE classes.

For SIMD, I think Intel compiler's auto-vectorization is pretty good now, In 
order to use SSE or AVX instructions automatically, the code needs to satisfy 
several requirements like using structure of array instead of using array of 
structure. Eigen library is doing pretty good on SIMD optimization now. 
http://eigen.tuxfamily.org/index.php?title=FAQ#Vectorization I would like to do 
some work on this. However, i'm pretty new on libMesh. May be you can give me 
some instructions on how to start and what kind of benchmark we should choose. 
Thanks.


Sincerely Yours,

Lei Shi
----------


On Wed, Oct 24, 2012 at 3:17 PM, Roy Stogner 
<royst...@ices.utexas.edu<mailto:royst...@ices.utexas.edu>> wrote:

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

[https://app.yesware.com/t/d1fcbaa1b12e0f6b1beef0b50d5ebbd873d1b8f9/60141017ba4ee107b22a004887786ed2/spacer.gif][http://app.yesware.com/t/d1fcbaa1b12e0f6b1beef0b50d5ebbd873d1b8f9/60141017ba4ee107b22a004887786ed2/spacer.gif]
------------------------------------------------------------------------------
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<mailto:Libmesh-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
------------------------------------------------------------------------------
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

Reply via email to