Vorbis - Aug 2000 - Vorbis optimizations...

I was wondering about what the near and longer term future 
directions for optimization of Vorbis decompression are.

I am interested in using it as a replacement for MP3. But it
seems at this point (not certain about this) that Vorbis doesn't
really have much optimization implemented yet. By this I 
mean, for example, implementing something like MMX x86 
optimzations in order to speed up the decompression. 

At this point, rough guestimates suggest that Vorbis uses 
up about 2x the CPU cycles on a PC to decompress relative
to MP3.

What are the possibilities and what is the plan? I (we) might 
actually be able to contribute to this effort, as we might 
stand to benefit from it.

Paul

--- >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-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

On Fri, 11 Aug 2000, Pedriana, Paul wrote:
> I was wondering about what the near and longer term future 
> directions for optimization of Vorbis decompression are.
Check the list archives, particularly vorbis-dev. Monty recently suggested
that the MDCT transform would be a good place to start, being both
(allegedly) slow and an isolated fuctional unit.

Officially the focus has been on features and maintability, so in the
near term I'd avoid anything that affects code complexity (unless you want
to maintain your own fork. :-) Long term I can't speak for.

Hope that helps,
 -ralph


--
giles@ashlu.bc.ca
Early bird gets the worm, but the second mouse gets the cheese.

--- >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-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

At 04:00 PM 8/11/00 -0700, you wrote:
>I was wondering about what the near and longer term future 
>directions for optimization of Vorbis decompression are.
>
>I am interested in using it as a replacement for MP3. But it
>seems at this point (not certain about this) that Vorbis doesn't
>really have much optimization implemented yet. By this I 
>mean, for example, implementing something like MMX x86 
>optimzations in order to speed up the decompression. 
>
>At this point, rough guestimates suggest that Vorbis uses 
>up about 2x the CPU cycles on a PC to decompress relative
>to MP3.
>
>What are the possibilities and what is the plan? I (we) might 
>actually be able to contribute to this effort, as we might 
>stand to benefit from it.
Up to now, most of the work has been going into features, whilst attempting
to keep the code highly portable and readable. It's getting to the point
now where it makes sense to work on optimising the existing code, however. 

There are a number of fairly obvious targets for optimisation. It's
probably not (yet) worth going to assembly (MMX or whatever), because most
of the bottlenecks could be sped up fairly significantly simply rewriting
them for performance in C. Once that avenue is exhausted, replacing key
parts with assembly will probably be useful - but not yet.

Right now, as Ralph mentioned, the biggest performance killer is the
(i)MDCT - but others are working on that (Takehiro Tominaga, to name the
one I am aware of) - it might be worthwhile coordinating efforts with him.

I'd start out with doing a few profiling runs to get some info on where
things are being slow, and focus on one of the larger functional units
(possibly the other transforms, like curve->lpc, but I'm not sure how
slow
those are).

Michael

--- >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-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.