Fri 25 Nov 2016 01:17:12 PM UTC, comment #2:
Thanks, Rik, that explains what to do to fix the problem (though Octave should just produce an error, not crash).
By the way, that wiki article is very misleading. The limitation is not 2 GB of memory, but rather 2^31 elements.
In an installation not compiled with <code>--enable-64</code> this produces an error as expected:
<pre>
>> a = zeros (102410242048, 1, 'int8');
error: out of memory or dimension too large for Octave's index type
</pre>
If we reduce the volume by just one slice, we do not hit the limit. But if we also change the data type a larger one the memory used by the array can be much larger:
<pre>
>> a = zeros (102410242047, 1, 'int8');
>> b = zeros (102410242047, 1, 'double');
>> whos
Variables in the current scope:
Attr Name Size Bytes Class
==== ==== ==== ===== =====
a 2146435072x1 2146435072 int8
b 2146435072x1 17171480576 double
Total is 4292870144 elements using 19317915648 bytes
</pre>
Both arrays have a slightly less than 2^31 elements. But while array <code>a</code> is just under 2 GB, <code>b</code> is close to 16 GB.
That is the reason why I'm able to workaround the limitation by reading the file in batches of less than 2 GB: my files and arrays are larger than 2 GB, but the number of elements is less than 2^31 because I use float32 and int16.
|