[vorbis-dev] Optimisations

[Segher Boessenkool]

"Timothy J. Wood" wrote:
> 
> >They say they will in the near future support 16 operations at once. I don't think
> >they will be able to do four separate operations at once, so they most likely will
> >widen the registers
> 
>   That's sure be cool.

I'm afraid it's marketing hype. Me the cynical, not seen anything to the contrary...

> >Is just int->float bad, or float->int as well? i ask this, because I was pleasantly

[snipped]

>   This is one nice thing about Altivec -- it has a very fast path for both int->float and float->int.

I think it's very strange to have a fast float->int and a slow
int->float, 'cause
that one is much much simpler.

> >More generally, maybe all of the audience can help: what are the weakest points of all the
> >various processors Vorbis will be deployed on?
> 
>   Speaking from my experience trying to optimize Quake3 for Mac OS X, I find:
> 
> - Memory bandwidth
> - Int->Float conversion
> 
>   to be the two worst problems on the PPC.  Memory bandwidth probably isn't as big of an issue for Vorbis as for Quake, but 

My biggest problem on the 486WB/K5/K6/K7/K71 was memory bandwidth. Use
anything bigger than your
cache size for buffers, or *anything* bigger than a few lousy bytes as a
lookup-table, and you
die. That's x86 for you. grumbl.

> it might still have some effect for lookup tables that don't fit in cache.  This effect can be made less bad by using the 
> data cache touch instructions when possible.

You have to make sure results from lookup-tables will never make it into
your (1st level)
cache, poisoning effects. But this isn't possible in portable C.

We most probably will not be able to make any portable C, but most
likely some set
of macros will make the whole shambalooga into portable (i.e.,
inefficient) (but not
more inefficient than the current code) C.

>   The int->float conversion problems go away if you can use Altivec to do it (i.e., you have an array of ints and you need an array of floats and they are all in the right positions, etc.)

And they didn't update the normal FP insns? Pity. Maybe the FP insns
generate exceptions
the AltiVec ones don't? I hate it when exceptions slow the insns down;
there should be an
alternative non-exception, not slowed-down version available.

Segher zelf

--- >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.