octave-maintainers
[Top][All Lists]
Advanced

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

Re: Rethinking octave_idx_type


From: John W. Eaton
Subject: Re: Rethinking octave_idx_type
Date: Fri, 30 Dec 2016 15:14:15 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.4.0

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.

jwe




reply via email to

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