Re: Rethinking octave_idx_type

[Rik]

On 11/26/2016 02:27 PM, John W. Eaton wrote:
> On 11/25/2016 11:35 PM, Rik wrote:
>
>> Other than performance, I think it does make sense to become more
>> compatible with the STL.  I don't think we have to switch to an unsigned
>> type though.  2^63 = 9 x 10^18 elements and if each element is an IEEE
>> double that would be 70 exabytes.  I don't know of any personal PCs that
>> would need the extra bit of addressing from an unsigned type because
>> they actually have 140 exabytes of memory.
>
> Using size_t (which is unsigned) helps compatibility with the STL because
> that's what it uses for sizes and indexing.  But I agree it is not
> absolutely necessary.  We already get away with using a signed type and
> have dealt with most of the places where compilers warn about mixing
> signed and unsigned types.

My main idea is that we start to consider performance, in addition to other
issues like code clarity and maintainability, when making architectural
decisions on Octave.  And because Octave is such a large and complex piece
of software, intuition is not a very good guide to the effects of any
change.  When I try and increase performance I usually treat the system as
a black box and use empirical methods.  That's why I would like to know
whether there is much of a difference in runtimes for the test suite
between the 32-bit and 64-bit versions of Octave.  Or whether the resident
set size for the Octave binary is appreciably different between the two.

If we change the typedef for octave_idx_type then I think we should make
several small changes rather than one large destabilizing change.  It would
be better to move to ssize_t first, where we would only need to modify the
interaction with the Fortran libraries, rather than size_t, where we would
also have to find and correct every single instance where negative values
are used with octave_idx_type.

--Rik