[vorbis] MMX/3dNow! etc
safemode
safemode at speakeasy.net
Sat Sep 29 08:37:49 PDT 2001
On Saturday 29 September 2001 09:48, Gian-Carlo Pascutto wrote:
> On Sat, 29 Sep 2001, Andreas Karlsson wrote:
> > Hi,
> >
> > I´m new on this list so I really don´t know that kind of questions have
> > been asked, but here I go.
> > Is the current ogg plug-ins using any mmx or 3dnow! instructions? Is
> > there any performance to gain?
>
> Segher is working on optimizing Vorbis, and currently
> focussing on the decoding.
>
> For now, it seems that the performance can be improved quite a bit
> without having to revert to special multimedia instructions (which
> aren't portable to other systems).
>
> A simple way to take use of MMX/SSE/SSE2 would be to recompile
> the Vorbis libraries with Intel C 5 with autovectorization enabled.
>
> The gain would likely be negligible though.
Yes i know the discussion is about decoders but to avoid flames over which is
better etc, i tested lame, which is obviously the best mp3 encoder :)
lame currently doesn't support libvorbis rc1 (at least on my system it errors
out when compiling) so i tested with encoding mp3s.
My tests with lame reflect your statement. The difference between mmx
enhanced lame and non-mmx is 21.6 seconds per 74min of audio on an athlon.
Seems that in encoding, there is little to lend to the multimedia
instructions. definitely not enought to warrant the time needed to recode it
to use the instructions.
Decoders would fall under the same catagory.
The thing is, this is on an athlon, which already has really good int and
floating point processing. weaker pentium cpu's may benefit more from mmx
than an athlon would. lame does not use 3dnow so that's the only thing i can
compare to. Anyone want to concur that mmx in lame on pentium cpu's shows
little difference? I suspect that the difference on pentium cpu's between
mmx and non-mmx would grow as you moved from P3 to P2 to P1. So despite my
previous statements, perhaps it would be worthwhile to give libvorbis and
libogg etc the option to compile in multimedia instructions to help lessen
the load on these weaker cpu's that, without them, would have trouble
encoding and playing ogg files. That is, they would experience a
significantly higher cpu usage than decoding and encoding mp3s would cause.
by the way, can a pentium 166 decode a "cd quality" ogg file? It would be
nice to see the difference mmx makes on that cpu. It's hard to see the
difference on an athlon where decoding high quality vbr mp3s never peaks over
1% but on cpu's where i remember winamp having trouble even playing normal
quality mp3s; i imagine utilizing those routines would give a more obvious
result. What you're saying is that it's not worth the effort. But for the
many people who use spare boxes for "music consoles" or those who just dont
have strong hardware, it may make the difference of being able to play ogg
files and being forced to stick to mp3s.
I just think there should be some testing to see if such instructions would
be worth taking the time to program before they're brushed away.
--- >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 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.
More information about the Vorbis
mailing list