dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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 <logg@xxxxxxxxx> 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 <logg@xxxxxxxxx> 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 <logg@xxxxxxxxx> 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 <logg@xxxxxxxxx> 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.

--
Anders