From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-10-24 21:09:38
|
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" <sto...@gm...<mailto:sto...@gm...>> 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 <roy...@ic...<mailto:roy...@ic...>> 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 Lib...@li...<mailto:Lib...@li...> https://lists.sourceforge.net/lists/listinfo/libmesh-devel |