[vorbis-dev] SIMD instructions

[Segher Boessenkool]

Monty wrote:
> 
> 
>>1.
>>SSE2 uses 64-bit floats, Vorbis uses 32-bit...
>>If we use 64-bit precision instead of 32, the result will be different.
> 
> 
> You get slightly different rounding.  It doesn't matter one bit
> (actually... it matters considerably less than one bit).  No aspect of
> Vorbis for which an arithmetic result is roundoff-sensitive uses
> floats.

Huh?  That can't be what you meant.

>>I've made an encoder/decoder with 64-bit precision
>>(I've changed float(s) to double(s) almost everywhere),
>>but the sound-result has changed, the tone was a little
>>different (not correct).
> 
> Then you have a bug, or you're imagining the problem.  You ears have
> given you a hint, now go use some tools that can tell you for certain.

100% agreed.

> I expect that
> even with rc3 in assembly, the 1.0 version wins on performance.

To that, too.

> Segher is right:

And to that, of course.

> Memory use patterns are a good initial target.

Attack plan:

-- everything should fit into cache/sram;
-- except possibly huge huffman books: find an efficient
    way to handle those.

> Otherwise, you'll get yourself into a position where you have a
> difficult-to-maintain assembly Vorbis decoder that took a long time to
> write being outperformed by a carefully tuned pure-C version that took
> less time to make.

If "assemblification" took more time, or even a significant portion
(like 10%) of the time needed to do algorithmic improvements, you're
doing something terribly wrong indeed.  Small easy significant-gain
hacks is where assembler code shines.

 > It's happened to GOGO and LAME, where the C tuning
> outperformed the original translation into assembly, and the assembly
> took ten times as long.

Really ten times?  Wow.

The worst thing about assembly in a context like this is that it
is obsolete almost as soon as you write it, being obsoleted by either
code changes or target changes (newer cpu's need different scheduling
and/or code selection).  The second doesn't apply if you control the
target hardware, i.e. you write it for local use only or you are
a hardware manufacturer.

<p>But by all means, go ahead if you really want to.

<p>Segher

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