dolfin team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

On Monday 01 June 2009 23:16:44 Garth N. Wells wrote:
> Johan Hake wrote:
> > On Monday 01 June 2009 16:53:55 Garth N. Wells wrote:
> >> Anders Logg wrote:
> >>> On Mon, Jun 01, 2009 at 04:06:40PM +0200, DOLFIN wrote:
> >>>> One or more new changesets pushed to the primary dolfin repository.
> >>>> A short summary of the last three changesets is included below.
> >>>>
> >>>> changeset:   6245:30c1540b12097130e3ed48ed572819471c884a7b
> >>>> tag:         tip
> >>>> user:        "Garth N. Wells <gnw20@xxxxxxxxx>"
> >>>> date:        Mon Jun 01 15:06:26 2009 +0100
> >>>> files:       dolfin/la/EpetraSparsityPattern.cpp
> >>>> dolfin/la/EpetraSparsityPattern.h dolfin/la/GenericSparsityPattern.h
> >>>> dolfin/la/SparsityPattern.cpp dolfin/la/SparsityPattern.h
> >>>> dolfin/la/uBLASMatrix.h description:
> >>>> Use std::set in SparsityPattern.
> >>>>
> >>>> Some performance issues seem to have been resolved with std::set.
> >>>>
> >>>> std::tr1::unsorted_set is faster, but requires some effort to sort.
> >>>> Sorting is only relevant to the uBLAS backend at this point.
> >>>
> >>> Building the sparsity pattern seems to be slightly faster, but
> >>> deleting it takes significantly longer. The relative slowdown for that
> >>> step is a factor 15-20.
> >>>
> >>> I was wondering why we used std::vector instead of std::set, but this
> >>> might be the reason: It takes a *long* time to delete std::set. We
> >>> should look for something else.
> >>
> >> I recall set insertion also being dead slow, which is why I used
> >> std::vector with a homemade insert. Despite having programmed it, it
> >> took me a bit to understand what the code I wrote does which I why I
> >> tried set again.
> >>
> >> We should try std::tr1::unsorted_set. It's faster for insertion but I
> >> don't know about the delete. We can cook something up to do the sort for
> >> uBLAS.
> >
> > Isn't the performance issue on destruction the common problem of deleting
> > a lot of small objects? This would probably not be any difference with
> > unsorted_set?
>
> We don't see this with std::vector<std::vector<uint> >. 

Which should be expected as the uints are stored in contigous arrays, making 
destruction cheap. In a set each uint is stored seperatly.

> unsorted_set 
> does have the same problem with slow destruction, but this is
> compensated for by faster insertion.

Ok.

Johan

> > Would it be worth trying a pooled memory management? Something like:
> >
> > #include <boost/pool/pool_alloc.hpp>
> > typedef std::set<int, unsigned int, boost::fast_pool_allocator<unsigned
> > int> > setuint;
>
> Yes, this is an option.
>
> Garth
>
> > Johan
> >
> >> Garth
> >>
> >>> -----------------------------------------------------------------------
> >>>-
> >>>
> >>> _______________________________________________
> >>> DOLFIN-dev mailing list
> >>> DOLFIN-dev@xxxxxxxxxx
> >>> http://www.fenics.org/mailman/listinfo/dolfin-dev
> >>
> >> _______________________________________________
> >> DOLFIN-dev mailing list
> >> DOLFIN-dev@xxxxxxxxxx
> >> http://www.fenics.org/mailman/listinfo/dolfin-dev