On Thu, 20 Feb 2014, Roman Vetter wrote: > they run ~50% slower overall. Profiling revealed that this slow-down > is caused by those parts of my programs that consist of simple loops > over mesh nodes and system variables, like (simplified): > > for (unsigned int nid = 0; nid < mesh.n_nodes(); nid++) > for (unsigned int var = 0; var < 3; var++) > use(some_vector(mesh.node(nid).dof_number(0, var, 0))); > > Such code runs ~3x slower than before. Surprising, isn't it?
Quite a bit. Can you put together a short demonstration code? I'd like to try bisecting the problem. > From the recent change in the global dof ordering (used to be > grouped by variables in ~v0.7, is now grouped by nodes), you'd > expect a clear speedup due to better cache locality, but instead, > the opposite happens. > > Any ideas why? Also, why and when was the dof order changed? Well, it's entirely possible that the dof_number lookup is slower than before. IIRC since 0.7 we've had two swaths of changes to the underlying storage type, both designed to optimize memory usage (where our DoF indexing is often significant) but without consideration for dof_number() performance (where fewer codes have a bottleneck). It's been a *long* time since 0.7, though... speaking of memory vs speed tradeoffs, is it possible you're using a ghosted some_vector now where you were using a serialized vector before? --- Roy ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
