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. 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? 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
