dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Jun 01, 2009 at 04:14:48PM +0100, Garth N. Wells wrote:
> 
> 
> Anders Logg wrote:
> > On Mon, Jun 01, 2009 at 03:53:55PM +0100, 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.
> > 
> > That sounds good. I've added a comment to SparsityPattern so we don't
> > forget about it.
> >
> 
> I had it running earlier and it's only a small change so I'll make it now.
> 
> Garth

ok! Once you're done, I can rerun the assembly benchmark to see what
numbers we get.

We're planning to set up a benchbot to run all benchmarks nightly
to keep track of any regressions. As features and interfaces are
becoming more stable, we need to start looking more closely at
performance.

-- 
Anders

Attachment: signature.asc
Description: Digital signature