On Wed, 29 Aug 2012, Lorenzo Alessio Botti wrote: > You can always store quantities that you need several times but this > might eat up a lot of memory. Accessing to memory might be expensive > and sometimes it might be even faster to recompute.
This can absolutely be true - on modern processors some problems end up, even in the assembly, bottlenecked by memory bandwidth rather than CPU speed. At that point anything that you can compute based on data that's already in the processor cache is "free". > The libMesh approach is to recompute everything. That's the libMesh examples approach, anyway, but that's intended to keep the examples simple more than anything else, I thought. When profiling real applications I've found that finding ways to cache transcendental function evaluations (e.g. by doing nodal quadrature or reinterpolation of such terms) can give a decent savings in runtime. Of course efficiency discussion is influenced by the fact that all the main libMesh developers are profiling based on our own app codes: implicit solves with intricate constitutive models. If you're doing an explicit calculation then it probably makes sense to cache even mappings and shape functions; if you're solving a linear problem then you could do much better with Rob Kirby's element matrix transformation tricks than with plain quadrature; etc. --- Roy ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
