On Wed, Nov 14, 2012 at 05:06:13PM +0000, Garth N. Wells wrote: > On Tue, Nov 13, 2012 at 6:40 PM, Anders Logg <l...@simula.no> wrote: > > On Tue, Nov 13, 2012 at 06:35:26PM +0000, Garth N. Wells wrote: > >> On Mon, Nov 12, 2012 at 8:39 AM, Anders Logg <l...@simula.no> wrote: > >> > On Mon, Nov 12, 2012 at 08:37:47AM +0000, Garth N. Wells wrote: > >> >> On Mon, Nov 12, 2012 at 8:31 AM, Anders Logg <l...@simula.no> wrote: > >> >> > On Sun, Nov 11, 2012 at 09:33:01PM +0000, Garth N. Wells wrote: > >> >> >> On Sun, Nov 11, 2012 at 7:36 PM, Anders Logg <l...@simula.no> wrote: > >> >> >> > On Sun, Nov 11, 2012 at 10:22:12AM +0000, Garth N. Wells wrote: > >> >> >> >> On Fri, Oct 26, 2012 at 6:22 AM, Anders Logg <l...@simula.no> > >> >> >> >> wrote: > >> >> >> >> > On Mon, Oct 22, 2012 at 10:32:11AM +0100, Garth N. Wells wrote: > >> >> >> >> >> We have discussed briefly in the past changing from unsigned > >> >> >> >> >> int > >> >> >> >> >> (typedef uint) to std::size_t. Starting to solve some really > >> >> >> >> >> big > >> >> >> >> >> problems and some changes in Trilinos make it a good time to > >> >> >> >> >> bring > >> >> >> >> >> this up again. Any thoughts or objections to moving to > >> >> >> >> >> std::size_t > >> >> >> >> >> from uint? > >> >> >> >> > > >> >> >> >> > I think this would be a good idea. > >> >> >> >> > > >> >> >> >> > >> >> >> >> I've started making some unsigned int -> std::size_t changes as I > >> >> >> >> restructure mesh partitioning. > >> >> >> >> > >> >> >> >> > I suggest we keep the uint typedef and make it point to size_t. > >> >> >> >> > > >> >> >> >> > >> >> >> >> I think we should use std::size_t and not uint. std::size_t is > >> >> >> >> already > >> >> >> >> a typedef and it conveys an intention: big enough for the largest > >> >> >> >> array that can be allocated on a machine. Also, it's not a > >> >> >> >> question > >> >> >> >> of unsigned int or std::size_t - there are places for both. > >> >> >> > > >> >> >> > So we will keep dolfin::uint for stuff like component indices and > >> >> >> > other small integers, and use size_t for everything that can > >> >> >> > potentially be large? > >> >> >> > >> >> >> Yes. I lean towards using 'unsigned int' instead of 'dolfin::uint'. > >> >> > > >> >> > Why? To minimize internal typedefs? > >> >> > > >> >> > >> >> Yes. Typing 'unsigned int' in full doesn't bother me. > >> > > >> > I don't feel strongly about it, as long as we're consistent. > >> > > >> >> >> > How about the Mesh? Should we use size_t for stuff like mesh > >> >> >> > connectivity? > >> >> >> > > >> >> >> > >> >> >> If it can potentially be big, then it should be std::size_t. > >> >> > > >> >> > Is the assumption that global dof numbers need size_t while for local > >> >> > entity indices (to a process) it's enough with uint? > >> >> > > >> >> > >> >> I would suggest using std::size_t for local indices. > >> >> > >> >> I've used unsigned int for things like topological and geometric > >> >> dimensions, number of connected entities, number of entities per cell, > >> >> etc. > >> > > >> > Is there a performance/memory hit? > >> > > >> > >> There should be no performance hit (some small improvements in places > >> where we will be able to avoid some copying). > >> > >> I've almost finished a transition, with just a few tests to sort out. > >> It's a bit tricky on the Python side because we can't expose uint and > >> std::size_t because the two will clash on 32-bit machines. It also > >> turns out that we have been making assumptions as to the PetscInt type > >> and the Trilinos int type which can't really justify. > >> > >> It will use more memory, but I'll have to test to see how much. I > >> expect that it's just a price that has to be paid to get to really big > >> problems. We can reduce the std::size_t usage from what I have now if > >> we fix some classes. Some data structures are used to store the cell > >> index, which means that they must be of type std::size_t, and this > >> propagates to parts of the code where std::size_t is not required. > >> std::size_t can be unwound to uint step-by-step. > > > > ok. I agree size_t is a necessary transition to get to bigger > > problems. > > > > I've almost got all the tests running with the size_t transition. I'd > like to merge as soon as the tests pass because the nature of the > branch means that it's impossible to maintain outside of trunk. It > will need some testing to make sure that it works on all platforms. It > may be that bugs in older versions of SWIG (< 2.07) will become > apparent. > > Some Python code will need minor changes (uintc -> unitp) and the C++ > code will need to make some dolfin:uint -> std::size_t changes. It > should all be relatively minor. > > There will be a temporary performance regression in the linear > algebra insertion because I'm copying matrix and vector indices to get > the types right. The plan is to introduce a special typedef to match > the linear algebra backend, i.e. if PETSc is the target backend then > the typdef will be for PetscInt. This will handle the cases where > PETSc is compiled with 32 or 64 bit integers without doing any > copying. It will also eliminate the casts that we presently have in > the linear algebra backends. This typedef will only appear in > GenericTensor::set/add/get and related functions. > > Let me know asap if there are any objections to an imminent merge.
No objections, better sooner than later. -- Anders _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : dolfin@lists.launchpad.net Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
