← Back to team overview

dolfin team mailing list archive

  1. dolfin team
  2. Mailing list archive
  3. Message #08891

Re: Fwd: Assembly benchmark

  Thread Previous • Date Previous • • Thread Next 


Anders Logg wrote:

On Wed, Aug 06, 2008 at 01:44:24PM +0100, Garth N. Wells wrote:


Anders Logg wrote:

On Wed, Aug 06, 2008 at 06:10:33AM -0500, Matthew Knepley wrote:

On Wed, Aug 6, 2008 at 5:00 AM, Anders Logg <logg@xxxxxxxxx> wrote:

On Wed, Aug 06, 2008 at 04:24:36AM -0500, Matthew Knepley wrote:

---------- Forwarded message ----------
From: Matthew Knepley <knepley@xxxxxxxxx>
Date: Wed, Aug 6, 2008 at 4:24 AM
Subject: Re: [DOLFIN-dev] Assembly benchmark
To: "Garth N. Wells" <gnw20@xxxxxxxxx>


On Wed, Aug 6, 2008 at 4:20 AM, Garth N. Wells <gnw20@xxxxxxxxx> wrote:

ok, here's the page, let's see some numbers:

  http://www.fenics.org/wiki/Benchmark


I just added my results.

The most obvious difference in our systems is 32/64 bit which could
likely account for the differences. MTL4 seems considerably faster on
the 32 bit system.

I need to understand the categories into which the time is divided:

 1) They do not add to the total (or even close)

There are 8 tables:

 0 Assemble total
 1 Init dof map
 2 Build sparsity
 3 Init tensor
 4 Delete sparsity
 5 Assemble cells
 6 Overhead

 7 Reassemble total

The first is the total and includes 1-6 so tables 1-6 should
add up to table 0. In fact, table 6 ("Overhead") is computed as the
difference of table 0 and tables 1-5.

Then table 7 reports the total for reassembling into a matrix which
has already been initialized with the correct sparsity pattern (and
used before).

Maybe there's a better way to order/present the tables to make this
clear?


 2) I am not sure what is going on within each unit

 1 Init dof map

This one does some initialization for computing the dof map. The only
thing that may happen here (for FFC forms) is that we may generate
the edges and faces if those are needed. You can see the difference
for P1, P2 and P3.

Don't understand why this is different for any of the backends.

It's the same, or should be. The benchmark just runs each test case
once so there may be small "random" fluctuations in the numbers.

The numbers of Table 1 are essentially the same for all backends.


 2 Build sparsity

This one computes the sparsity pattern by iterating over all cells,
computing the local-to-global mapping on each cell and counting the
number of nonzeros.

Same question.

This should be the same for all backends except for Epetra. The DOLFIN
LA interface allows for overloading the handling of the sparsity
pattern. For Epetra, we use a Epetra_FECrsGraph to hold the sparsity
pattern. It seems to perform worse than the DOLFIN built-in sparsity
pattern (used for all other backends) which is just a simple
MTL4 isn't using a sparsity pattern. A guess is just being made as to the number of non-zeroes per row. 


  std::vector< std::set<uint> >


It's now a

     std::vector< std::vector<uint> >
which is faster than using std::set. Only uBLAS needs the terms to be ordered (std::set is ordered), so I added SparsityPattern::sort() to do this. 

Garth


I didn't know. I'm surprised that doing a linear search is faster than
using std::set. I thought the std::set was optimized for this.
std::set was dead slow, which I attributed to it being ordered and therefore requiring shuffling after insertions. I tried std::tr1::unordered_set, but it wasn't much better. 

Garth

Follow ups

References

  Thread Previous • Date Previous • • Thread Next