Re: [eigen] Re: Index types change pushed

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

Oh! No idea why, either.
It probably has something to do with having offsets now the of the
same size as pointers, but no idea exactly why this is helping.
Benoit

2010/6/1 Eamon Nerbonne <eamon.nerbonne@xxxxxxxxx>:
> When this change was discussed, I expressed worry that the larger 64-bit
> integers might degrade performance.  Well, I ran a quick test on my own
> project to check, and indeed the performance changed - it's 4-10% faster
> now, with the bigger ints.  I have no idea why, but I'm not complaining :-).
>
> --eamon@xxxxxxxxxxxx - Tel#:+31-6-15142163
>
>
> On Sun, May 30, 2010 at 23:58, Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
> wrote:
>>
>> by the way, if you wonder why the _template parameters_ and other
>> compile-time values are still int, that's because for compile-time
>> constants,
>> 1) it won't be a huge value so int is always big enough
>> 2) there's no concept of sizeof or it doesn't matter.
>>
>> I didn't want to have to worry about the types of compile-time
>> constants as that was just abstract nonsense.
>>
>> Benoit
>>
>> 2010/5/30 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>:
>> > Hi list,
>> >
>> > The huge "index types" change is pushed to the development branch.
>> >
>> > *** What changed ***
>> >
>> > Before, we used type int for all indices. A recent huge thread on this
>> > list showed that while the choice of a signed type was sensible, it
>> > would be good to make it more adaptable. This is what this change
>> > does:
>> >  - dense matrices now default to std::ptrdiff_t, which means that
>> > you're sure to be able to address half the size of your address space
>> > (half, because it's signed).
>> >  - sparse matrices are still using int, because the sizeof() matters a
>> > lot there (since we are story arrays of indices).
>> >
>> > You can change that at will by defining EIGEN_DEFAULT_DENSE_INDEX_TYPE
>> > and EIGEN_DEFAULT_SPARSE_INDEX_TYPE. Of course, this breaks ABI
>> > compatibility.
>> >
>> > In the future we'll probably add an option to Sparse matrix types to
>> > specify different index types. On the other hand, for Dense matrices,
>> > I don't think there can ever be a valid reason to use something else
>> > than ptrdiff_t. Notice that for fixed-size matrices, this doesn't have
>> > any cost as the sizes aren't stored as runtime variables.
>> >
>> > *** How this works ***
>> >
>> > This works per-StorageKind. So if in the future we add a new
>> > StorageKind for "Dense matrix stored over distributed storage", we're
>> > free to specify e.g. long long int for them, without affecting the
>> > rest.
>> >
>> > See in XprHelper.h, the new struct ei_index, see this code:
>> >
>> >
>> > template<typename StorageKind> struct ei_index {};
>> >
>> > template<>
>> > struct ei_index<Dense>
>> > { typedef EIGEN_DEFAULT_DENSE_INDEX_TYPE type; };
>> >
>> > typedef typename ei_index<Dense>::type DenseIndex;
>> >
>> >
>> > Then in the macro EIGEN_DENSE_PUBLIC_INTERFACE, we now have:
>> >
>> >  typedef typename Eigen::ei_traits<Derived>::StorageKind StorageKind; \
>> >  typedef typename Eigen::ei_index<StorageKind>::type Index; \
>> >
>> > this means that all expressions have a Index typedef that means the
>> > right thing. Normally, we propagate this recursively as appropriate.
>> > However there are some contexts where we know we are only dealing with
>> > Dense expressions, and don't have a MatrixType to work with (e.g. in
>> > some public functions). There, it's OK to specify explicitly
>> > DenseIndex.
>> >
>> > Then, we have the same thing in the Sparse module, in SparseUtil.h:
>> >
>> > template<>
>> > struct ei_index<Sparse>
>> > { typedef EIGEN_DEFAULT_SPARSE_INDEX_TYPE type; };
>> >
>> > typedef typename ei_index<Sparse>::type SparseIndex;
>> >
>> >
>> > etc, etc.
>> >
>> > Benoit
>> >
>>
>>
>
>