Re: OCTAVE_LOCAL_BUFFER

[Jaroslav Hajek]

On Wed, Dec 10, 2008 at 2:50 PM, John W. Eaton <address@hidden> wrote:
> On  6-Dec-2008, Jaroslav Hajek wrote:
>
> | OK, the new code for OCTAVE_LOCAL_BUFFER is uploaded. It appears that
> | octave_fcn_handle::load_binary relied on the old behaviour of using
> | std::vector (which always default-initializes elements). I believe
> | that OCTAVE_LOCAL_BUFFER was not intended to be initialized, so I
> | fixed the offending code.
>
> Right, it was intended as uninitialized space.
>
> | The current state is as said above: a buffer < 8K is allocated on the
> | stack (if dynamic stack arrays are supported), otherwise via normal
> | new[] allocation.
> | I'm not sure 8K is the best constant, but stack is a very limited
> | resource, and its overflow is typically unrecoverable, so I tried to
> | be conservative...
>
> I don't know of a good way to decide whether that will cause trouble.
>
> | There is a more sophisticated optimization of local buffers possible.
> | Since they have a FIFO semantics, it is possible to allocate big
> | chunks (say, 16 MB) in a stack-like manner and serve local buffers
> | from them. Obstacks from the GNU C library are based on the same idea
> | (except that using obstacks would be an overkill, because we would
> | need only a small subset of their functionality).
> |
> | opinions?
>
> That would probably be a better way to go, as it would avoid any stack
> resource limitations.  Also, we could grow the buffer (or add more
> buffers to a list) as needed.
>

Yes, I thought of it like that. It's on my TODO list. If that's
implemented, we could probably disable stack arrays at all, because
they have no significant advantages over this. (except that the
compiler allocates a stack arrays very fast (single instruction), but
OTOH the 8K safekeeping outweighs that).

> I'm not sure it is necessary to do this just now, but given the number
> of uses of OCTAVE_LOCAL_BUFFER, we may see some complaints about
> Octave crashing due to running out of stack space without it.  If we
> do, then I think we'll have to either disable the local stack
> optimization or implement something like you are suggesting.
>

Maybe we could disable it on windows, as it is known to have more
problems with stack space which IIRC can't be easily set up by user.

> jwe
>



-- 
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz