Re: Rethinking octave_idx_type

[Mike Miller]

On Fri, Nov 25, 2016 at 20:35:41 -0800, Rik wrote:
> Are there any performance implications?  Most people will still not need
> regular access to matrices with more than 2^31 elements.  By potentially
> doubling the pointer size, you could increase the critical processor L1, L2
> cache requirements.  If there are still systems where Octave is run that
> have 32-bit busses then there is another big hit because each pointer will
> require two fetches.  In general, the march of progress is towards 64-bit
> systems and bigger caches so this will sort itself out, but have we crossed
> over the point where 50% of Octave systems are 64-bit?

The proposal was to use ssize_t (or maybe size_t someday). These types
are 8 bytes wide on 64-bit systems and 4 bytes wide on 32-bit systems.
Were you concerned about using a 64-bit index/pointer on all systems? I
don't think that's what we're talking about.

On 32-bit systems, nothing would change. The octave_idx_type would still
be a 32-bit signed number (or maybe unsigned someday) and would still
interface with native Fortran libraries built to use 32-bit integers.

On 64-bit systems, octave_idx_type would now be a 64-bit value, and
additional logic would have to be put in place now to ensure that we
don't pass 64-bit array sizes into BLAS and other Fortran libraries,
unless the user builds Octave with --enable-64.

Is it possible today to build Octave on a 32-bit system with
--enable-64? I wouldn't think it would be possible or desirable to do
so. If it is, then this proposal would probably break that use case.

But please correct me if I got something wrong here.

-- 
mike