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>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<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
