dolfin team mailing list archive

["Johan Hoffman" <jhoffman@xxxxxxxxxx>]

> On Wed, 2006-03-29 at 16:59 -0600, Anders Logg wrote:
>> On Thu, Mar 30, 2006 at 12:58:37AM +0200, Garth N. Wells wrote:
>> > On Wed, 2006-03-29 at 16:56 -0600, Anders Logg wrote:
>> > > On Thu, Mar 30, 2006 at 12:51:13AM +0200, Garth N. Wells wrote:
>> > > > On Wed, 2006-03-29 at 16:45 -0600, Anders Logg wrote:
>> > > > > On Thu, Mar 30, 2006 at 12:38:36AM +0200, Garth N. Wells wrote:
>> > > > >
>> > > > > > > Another option would be to dig up the old DenseMatrix
>> (attached) from
>> > > > > > > before we removed it in version 0.5.5.
>> > > > > > >
>> > > > > >
>> > > > > > I took a look at this earlier today. I thought that if we
>> followed this
>> > > > > > approach, it was worth considering an external library to cut
>> down on
>> > > > > > code and while offer the same or more features.
>> > > > >
>> > > > > Agree!
>> > > > >
>> > > > > > > But before we do anything more about this, it would be good
>> to see
>> > > > > > > some benchmarks to motivate why this can't be handled by
>> PETSc. We use
>> > > > > > > a lot of small PETSc matrices in the ODE solvers and it
>> seems to work
>> > > > > > > ok.
>> > > > > > >
>> > > > > >
>> > > > > > I'll take a look. Are you creating PETSc dense matrices, or
>> are you
>> > > > > > using dolfin::Matrix?
>> > > > > >
>> > > > > > Garth
>> > > > >
>> > > > > Just Matrix without any options.
>> > > > >
>> > > >
>> > > > My experience is that this is extremely slow, particularly when
>> > > > accessing values. You have all the overhead of the the sparse
>> storage
>> > > > scheme.
>> > > >
>> > > > Garth
>> > >
>> > > What if we add Matrix::dense to the matrix types (mapped to PETSc
>> > > MATDENSE)? Would that help?
>> > >
>> >
>> > Might do. I'll set up some benchmarks to check it out.
>> >
>> > Garth
>>
>> Great. Let's hope it's enough. It would be the simplest solution.
>>
>
> I've done some benchmarking for various ways to set the values by index
> and to retrieve them by index in a small matrices. With the way we
> currently use PETSc, it's about 500-600 times slower for insertion that
> any other technique (this is for dense PETSc matrices). This is due to
> the calls
>
>   MatAssemblyBegin(A, MAT_FINAL_ASSEMBLY);
>   MatAssemblyEnd(A, MAT_FINAL_ASSEMBLY);
>
> after inserting each value each value.
>
> For a full 6x6 matrix which is assembled 1e7 times, the normalised
> timings were
>
> PETSc*:                   25
> Boost multi_array class:  8
> Boost ublas::matrix:      1.7
> std::vector based matrix: 4.8
> standard array:           1
>
> *with MatAssemblyBegin(..) and MatAssemblyEnd(..) called only after the
> insertion of all 6x6 terms.
>
> The timings for retrieving values are similar. Based on this, I think a
> simplified version of the old DenseMatrix class would be best (at least
> for my applications). If we're willing to accept a boost dependency,
> uBlas is very nice.

Interesting! I guess the ODE solver could take advantage of such a speed up?

/Johan






>
> Garth
>
>> /Anders
>>
>> _______________________________________________
>> DOLFIN-dev mailing list
>> DOLFIN-dev@xxxxxxxxxx
>> http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev
>
>
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev
>