On Mon, Aug 11, 2008 at 05:49:22PM +0100, Garth N. Wells wrote: > > > Dag Lindbo wrote: > > Anders Logg wrote: > >> On Mon, Aug 11, 2008 at 10:32:23AM +0200, Dag Lindbo wrote: > >>> Hello! (I've been out of e-mail range for a week) > >>> > >>> I've posted some results on the wiki (and I actually have MTL4 :-) ) > >>> where I just show total assembly times with and without optimization > >>> turned on. MTL4 responds quite well to -O3 (unlike uBLAS). > >>> > >>> As far as the MTL4 backend goes, I have implemented and tested almost > >>> all the operators and member functions. We are running into some quirks > >>> with namespaces in MTL4 which Peter G is going to sort out. Also, there > >>> is a bug somewhere in the version of the backend currently in place -- > >>> so please don't use it without manually initializing matrix dimensions. > >>> > >>> I will sort this out in a day or two and then have a bundle ready that > >>> finalizes the MTL4 backend. The performance results have been > >>> encouraging enough to keep me (and Garth) motivated to get this backend > >>> ready for "real" use. > >>> > >>> /Dag > >> Good. I've updated my results (this time with MTL4 actually installed) > >> and MTL4 does very good. > >> > >> The problem is it's cheating. Other backends would also do much better > >> if they were allowed to guess the number of nonzeros and guess right. > >> > > > > Of course, PETSc should be just as fast as MTL4. uBlas, I don't think > > could. As far as Epetra goes, I have no understanding of the insertion > > procedure. The STL backend is cheating as well, since the matrix is not > > (as far as I know) in a state which is suitable for linear solve. > > > > In my opinion it really is necessary to give the user the option of > > specifying the number of nonzeros per row. Many forms get assembled a > > _lot_ (e.g. the ICNS-3D form used by Hoffman et. al. has not changed in > > years) and it seems absurd that DOLFIN should insist on recomputing the > > information that is already known by the user. > > > > The same form is not always assembled on the same mesh, which doesn't > make it possible to specify the non-zeroes based on the form alone. What > is likely to be the best approach is letting FFC create a function to > compute the maximum non-zeroes for a row based on mesh information.
And remove SparsityPatternBuilder? -- Anders > Apparently the necessary function already exists in UFC. Bear in mind > that for most computationally intensive applications the cost of > computing the sparsity pattern will be insignificant compared to the > multiple reassembly of the matrix (not that this means we shouldn't try > to make it better, but it should be remain generic). > > What you suggest with specifying the non-zeroes can be done within the > existing framework. A "sparsity pattern" could just constitute the > maximum number of non-zeroes on a row, and the matrix class can then > initialise the matrix as it wishes. It's also possible to access the > underlying matrix object and initialise it. > > I don't think a function > > GenericMatrix::init(uint m, uint n, uint nz_max) > > is suitable because it's not appropriate for all linear algebra backends > (e.g., uBLAS). > > Garth > > > There has been a lot of discussion of assembler performance on the list > > and so I made the MTL4 backend as a demonstration of how fast the core > > DOLFIN/FFC/UFC assembler design could be. I intend to keep trying to > > squeeze more performance out of DOLFIN and you may then decide if my > > suggestions are worthwhile or "cheating". > > > > /Dag > > > >> > >> ------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> DOLFIN-dev mailing list > >> [email protected] > >> http://www.fenics.org/mailman/listinfo/dolfin-dev > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > DOLFIN-dev mailing list > > [email protected] > > http://www.fenics.org/mailman/listinfo/dolfin-dev > > _______________________________________________ > DOLFIN-dev mailing list > [email protected] > http://www.fenics.org/mailman/listinfo/dolfin-dev
signature.asc
Description: Digital signature
_______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
