dolfin team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

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.

Garth

> --
> Anders
>