On Tue, Mar 10, 2015 at 11:07 AM, Martin Sandve Alnæs <[email protected]> wrote: > I don't understand how templating over the array type solves that. > The generated code would still need to index A as a flat array using > notation like A[i*m+j]. > > Also, I think the code generation should know about the alignment and > padding > of the input and output arrays, because that can be exploited. >
Yes, we should be looking at this. > What if, for example, we always require the element tensor rows to be > padded, > e.g. round up the number of dofs in the fastest running index of A to the > nearest > multiple of 4. Could we pass a padded matrix A directly to PETSc and make > PETSc ignore the padded values? > Yes, if we also pad the dofmaps for each cell with a negative index for the padded terms. Downside is that it starts getting quite specific to the linear algebra backend. Garth > > > > On 10 March 2015 at 11:41, Garth N. Wells <[email protected]> wrote: >> >> On Tue, Mar 10, 2015 at 10:29 AM, Martin Sandve Alnæs >> <[email protected]> wrote: >> > (Sorry if someone got this twice, the first was bounced because of the >> > long >> > thread). >> > >> > I fail to see the point of templating over array type. >> > >> > Calling resize() leads to dynamic allocation which is exactly why we >> > can't >> > use std::vector. >> > >> >> I don't see this a big problem. It only allocates is the size is >> wrong. I think such behaviour on the DOLFIN side is good, but not >> needed on the UFC side since users don't interface to UFC directly. >> >> > Having generated code call .size() on input arguments to determine array >> > lengths is useful >> > only in a few cases in ufc (mainly run-time determined quadrature >> > points), >> > and in most >> > cases would defeat optimizations based on known array sizes in the >> > generated >> > code. >> > >> > We have had extremely few cases of problems with indexing arrays out of >> > range >> > with [] in generated code, so range checking is not a significant >> > advantage >> > (except >> > maybe for the few power users who want to implement their own ufc code). >> > >> > More important, templating ufc over the array type has the disadvantage >> > of >> > changing >> > ufc from one interface to an "arbitrary" number of non-compatible >> > interfaces. >> > >> >> Of course the required container interfaces would need to be prescribed. >> >> A reason I floated the idea of templating, apart from complex number >> support, leads from some very recent experience with Eigen and the >> data() function. With Eigen, data() can be expensive, whereas for >> std::vector, etc it is very cheap. I put this down to Eigen using >> special pointer alignment to permit vectorisation, which means >> something fancy is done with data() to make the returned pointer >> useful. It can be useful to assemble into an Eigen data structure to >> further manipulate an matrix/vector, but the performance cost of >> data() make this a problem. >> >> Garth >> >> >> >> > Martin >> > >> > _______________________________________________ >> > fenics mailing list >> > [email protected] >> > http://fenicsproject.org/mailman/listinfo/fenics >> > > > _______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
