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
