[vorbis-dev] BeOS on PPC compile, thread question.

[Segher Boessenkool]

Monty wrote:
> 

Hey Monty, I agree with you on not wanting this, of course,
but you're exagerating.

> > Maybe I am missing something obvious, but if alloca() is simply allocating
> > from the stack, why not just replace these with stack buffers? For example:
> >
> > void function1(void)
> > {
> >       /* Define a buffer of max size, aligned to int, needed from the
> > stack. */
> >       int buf[256];
> >
> >       function2(buf);
> > }
> 
> Because you can't do 'alloca[non_static_var]', and many aspects of
> vorbis aren't bounded to small numbers.  Ie, you encourage lots of
> static buffer errors.

Just put a (compile time) check in it.

> > I'm sure people will answer "because you will waste stack space if you don't
> > need the max size and perhaps blow your stack".
> 
> No, you'll cause *lots* of cache pressure as things are scattererd a
> half meg apart on the stack.

Only if it's *exactly* half a meg, and you got a direct mapped cache (which,
unfortunately, nowadays everyone has).

> > I don't see that argument
> > holding up, because if you had a worst case vorbis stream come in, it would
> > still blow up with alloca() if it had to use larger allocations.

If your OS doens't support stacks of, like, 100/200k, you're doomed
anyway. Sorry.

> More like 'be very slow'.  Why be very slow 100% of the time instead
> of just in that 1 out of 10,000 streams?

Why would this be slow? It is just begging for (not so) subtle errors,
but slow?

> > Another idea is to pre-allocate a number of buffers of a large enough size
> > when your Vorbis_init() (not sure what the proper name is) type function is
> > done, then just re-use those each time to avoid the continual malloc/free.
> 
> This results in a 30+M footprint for decoding even very simple things.

Any sane OS doesn't reserve any physical memory for pages not yet used.

> > P.S. - I throw my 2 cents in that Vorbis shouldn't use Malloc/Free(), but
> > instead ask for  Malloc/Free() function pointers. These may be common in
> > desktop computing but they are absolutely shunned in some applications (e.g.
> > game consoles).
> 
> _ogg_malloc, etc, are defines in os_types.h now (a specific concession
> to folks who have made the console argument in the past).  It's not
> like the requirement of a different malloc would suddenly be a
> surprise at runtime...

But you still use the pool thing on top of this, right?

Ciao,

Segher

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.