octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Rethinking octave_idx_type


From: Philip Nienhuis
Subject: Re: Rethinking octave_idx_type
Date: Fri, 30 Dec 2016 22:50:45 +0100
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0 SeaMonkey/2.40

John W. Eaton wrote:
On 12/30/2016 02:26 PM, PhilipNienhuis wrote:
John W. Eaton wrote
With this changeset

   http://hg.savannah.gnu.org/hgweb/octave/rev/21707d6a02c7

the --enable-64 configure option is now the default.  Here's the NEWS
entry:

  ** On systems with 64-bit pointers, --enable-64 is now the default and
     Octave always uses 64-bit indexing.

What will be the anticipated effects for MXE cross-builds? (if any?)
Will -enable-windows-64 still work? (is it still needed?)

Yes, because without that, the compiler is configured to use 32-bit
pointers.  We will have the following options:

  ** 32-bit pointers and indexing (--disable-windows-64):
     You are limited to a total of 2^32 bytes of memory
     no matter how you slice it.  [A]

  ** 64-bit pointers (--enable-windows-64) three four additional options:

       32-bit indexing (--disable-64):  Individual array
       dimensions are limited to about 2^31 elements but
       you can allocate more than one, up to the system
       memory limits.  You should be able to use a BLAS
       library that uses 64-bit integers for indexing, but
       you won't be able to take advantage of the larger
       array capability of the libraries, so I'm not counting
       this as a reasonable possibility.

       64-bit indexing (--enable-64) and 32-bit BLAS, LAPACK, etc.:
       You are limited to a total of 2^64 bytes of memory and
       array dimensions may be up to 2^63 elements but libraries
       that use 4-byte integers for indexing will have smaller
       limits. [B]

       64-bit indexing (--enable-64) and 64-bit BLAS, LAPACK, etc.:
       Same array limits as the previous option, but without the
       smaller limits for BLAS, LAPACK, etc.  Some libraries like
       glpk and Qhull that use "int" may still have smaller limits.

[A] is still the default if you don't use either --enable-windows-64 or
--enable-64 when configuring mxe-octave.

[B] should be the default now if you use --enable-windows-64 but not
--enable-64 when configuring mxe-octave.  If you use --enable-64 you
will get the last option above (everything possible is built with 64-bit
indexing).

It might make sense to split the meaning of the mxe-octave configure
script's --enable-64 into two options:

   --enable/disable-64:
     Just set the option for Octave's configure script

   --enable-fortran-integer-8:
     Build BLAS, LAPACK, etc. using 8-byte INTEGER values by default

Also, I just noticed that the mxe-octave build disables Qhull when using
--enable-64.  I'm not sure why, though maybe we just haven't done the
work needed to impose limits on any integer values and arrays that are
passed to Qhull functions?  I guess it would be worth checking that out
for both Qhull and glpk.

Thank you for the explanation.

Philip




reply via email to

[Prev in Thread] Current Thread [Next in Thread]