Re: [eigen] Re: Index types change pushed

[ Thread Index | Date Index | More Archives ]

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
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.


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 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 typename ei_index<Sparse>::type SparseIndex;
> etc, etc.
> Benoit

Mail converted by MHonArc 2.6.19+