[vorbis-dev] Optimisations

[Segher Boessenkool]

Jason Hecker wrote:
> 
> >More generally, maybe all of the audience can help: what are the weakest
> >points of all the
> >various processors Vorbis will be deployed on?
> >
> >We'll need this in making reasonable decisions 'bout what/how to optimize.
> 
> Well, therein lies the problem.  I think once various bits of libvorbis
> code are identified that can be pulled out to generalise (for reuse
> throughout the program) and optimise, simply write a simple C version that

I'm afraid the only vector parts within Vorbis that are used in
multiple spots, are vector copies. Ummmh, *spurious* vector copies.
So "general" "utility" DSP functions ae not useful (at most one
time useful, whatever).

> can be used as a reference and let whomever figure how they want to
> implement the CPU specific optimisations.  I think it'd be foolhardy to set

Plan is, to rewrite critical parts of the C code, so to be more natural
to rewrite using a (possible assembler) vector implementation.
Nothing more; it's just simple unrolling && re-rolling. And the usual
putting-more-subroutines-into-one-and-refactoring-it-completely-different,
of course. make the code more natural to the machine, i.s.o. to the programmer.
I think Monty will hate me ;-)  (If not now, soon he will).

> in stone what sort of optimisation to use (ie must conform to a piece of C
> code that is say, unrolled and forces register usage that may not be nice
> to all CPUs).

That is not the target, don't be afraid :-) If you want to join us,
please tell;
anyone knowledgeable is welcome (as far as I'm concerned; I think Jason will
agree).

Byebye,

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.