On Jul 16, 2014, at 2:25 PM, John Peterson <[email protected]> wrote:

> The next thing I'll try is re-enabling tbb, but removing the
> scalable_allocator template parameters from dof_map.h and
> sparsity_pattern.h, and making sure we're still valgrind-clean.
> Assuming this works, what is the correct long-term fix?
> scalable_allocator seems to be an optimization, so the simplest
> approach is to just remove it...  I wouldn't be opposed to e.g.
> enabling it only when C++11 is enabled, although that is quite a hack,
> and only shows that we do not know what the real problem is.

IIRC the scalable allocator is almost a prerequisite to actually see a speedup 
with TBB here.  Otherwise there's so much per-thread allocation contention 
things can actually slow down, so I think we need to use it when possible.  
Might be worth profiling on a more recent system though rather than relying in 
my increasingly hazy memory.

Alternatively, does enabling C++11 give us any other allocator we can stick in 
there?

Also, just found this:

http://valgrind.org/docs/manual/dist.news.html
looks like bug #317318 

317318  Support for Threading Building Blocks "scalable_malloc"

should be fixed in valgrind 3.9.0.  What version are you running? 
------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Libmesh-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-devel

Reply via email to