> Quite a bit. Can you put together a short demonstration code? I'd
> like to try bisecting the problem.
> 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).
Indeed, further profiling points at a slower dof_number(). It's not the
dof ordering, but some other overhead in dof_number(). The following
minimal program demonstrates the problem:
//START MINIMAL WORKING EXAMPLE
#include "libmesh/libmesh.h"
#include "libmesh/mesh.h"
#include "libmesh/mesh_generation.h"
#include "libmesh/equation_systems.h"
#include "libmesh/explicit_system.h"
#include "libmesh/perf_log.h"
using namespace libMesh;
int main(int argc, char** argv)
{
LibMeshInit init(argc, argv);
Mesh mesh(init.comm());
MeshTools::Generation::build_line(mesh, 1000000, 0, 1, EDGE2);
EquationSystems equation_systems(mesh);
ExplicitSystem& s = equation_systems.add_system<ExplicitSystem>("s");
s.add_variable("u");
s.add_variable("v");
s.add_variable("w");
equation_systems.init();
double sum = 0;
const unsigned int n_nodes = mesh.n_nodes();
PerfLog perf_log("dof indexing");
perf_log.push("dof_number()");
for (unsigned int nid = 0; nid < n_nodes; ++nid)
{
const Node& node = mesh.node(nid);
for (unsigned int var = 0; var < 3; ++var)
sum += s.current_solution(node.dof_number(0, var, 0));
}
perf_log.pop("dof_number()");
std::cout << sum << std::endl;
return 0;
}
//END MINIMAL WORKING EXAMPLE
With SVN r5953, this code runs in 0.034 secs, while with the current git
HEAD, it takes 0.046 secs (in opt mode). That's only a slow-down of 35%,
not 200% as mentioned earlier. Something else must interfere in the much
larger code where I observed the 200%. However, even there, if I replace
the dof_number() call by a dirty hardcoded "3*nid+var", both versions
run equally fast, so it really is that function.
Well, it looks like I'll have to live with it as I don't reckon your
going to undo the changes made to dof_number().
> 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?
No, that's not the case. I have tested it with a std::vector instead of
libMesh::NumericVector, with the same result.
-Roman
------------------------------------------------------------------------------
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
_______________________________________________
Libmesh-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-users
