[vorbis] Why is ogg123 so much slower than XMMS?

[Firelight Multimedia]

Exactly, I can fool the w2k scheduler into thinking it is using less cpu
by just using a Sleep(10) (it goes to 0%!) in a decoding loop instead of
Sleep(5).
There is nothing better than actually sticking a cycle counter right in
the code, it's the only way to get true cpu usage.

<p>> -----Original Message-----
> From: owner-vorbis at xiph.org [mailto:owner-vorbis at xiph.org] On Behalf
Of
> Alen Ladavac
> Sent: Monday, 17 December 2001 8:54 AM
> To: vorbis at xiph.org
> Subject: Re: [vorbis] Why is ogg123 so much slower than XMMS?
> 
> People, are you trying to profile a program by using system monitoring
> tools? Again? It was discussed for Win32 last time on this ml (iirc),
but
> I
> don't see why would it be much more accurate under other OSs. I mean,
task
> schedulers are not ment to be used for profiling, they only give
> approximate
> info. The general rule of the thumb should be: don't use a tool for
> something it is not designed for.
> 
> Alen
> 
> ----- Original Message -----
> From: "safemode" <safemode at speakeasy.net>
> To: <vorbis at xiph.org>
> Sent: Monday, December 17, 2001 06:56
> Subject: Re: [vorbis] Why is ogg123 so much slower than XMMS?
> 
> 
> > On Sun, 2001-12-16 at 20:16, Joel wrote:
> > > > > I belive cpu-time isn't always reported correctly for xmms and
its
> > > > treads,
> > > > > (at least when using top to
> > > > > report). I didn't notice any change in %-of cpu-time between
> > > > xmms(stopped)
> > > > > or xmms(playing). Is this true
> > > > > in your case too?
> > > >
> > > > When stopped there are four threads of XMMS, none is taking CPU
> time.
> > > > When playing two more are created, and totally they eat 0.3~0.5%
on
> my
> > > > PII/233 (isn't noticeable, is it? :)
> > >
> > > That's why I suspect something is left out. I know from experience
> that
> a P75 _barely_ handles mp3 decoding (choppy sound). Suppose decoding
took
> 2%
> of your CPU-time, then (with some mathematic approximation) it should
be
> sufficent with a PII running at 0.02*233= 4.66MHz! Im my eyes, this is
> most
> unrealistic.
> > I was ok with the rest of the argument except this one really.  You
cant
> > compare clock rates as the deciding factor of cpu performance.  I
> > thought we knew better than that.  I'm willing to chock up the near
0%
> > cpu usage of current players on modern cpu's, video players too even
as
> > a kernel problem but using some kind of ratio to compare cpu's using
> > different instruction sets via clockrates is just silly.
> > on the other hand, perhaps they are using that much time, then it
would
> > be easier figuring out the situation that would be possible for them
to
> > do that since it would be a rather narrow amount of choices rather
than
> > figuring out what way it could be wrong, where you have an
uncountable
> > amount of places a coding error or design flaw could be found in.
> >
> > Even if the clockrates were the only thing different i'd still have
a
> > problem with this argument.  because the clockrates aren't even
measured
> > the same way on newer cpu's as they were back in the pentium days.
They
> > aren't even measured the same way between amd and intel currently.
> >
> > If you look at current cpu's,  they can do X amount of instructions,
> > now P75 could only do 1 instruction at a time, current cpu's like
the
> > athlon K7 can do 4 instructions at a time at most (optimized for it)
2
> > in other optimized code and so on.   The T-birds of late can do 8 if
i'm
> > not mistaken,  micro-ops they call them,  perhaps this is the P4,
either
> > way it doesn't matter which cpu does it.  just that newer cpu's can
do
> > on average 3 times more at a time not to mention the amount of times
it
> > can do that per second has increased exponentially.   So a well
> > optimized player can get more things done at a time in less time per
> > second on a modern cpu.  something that took a P75, say 90% of it's
> > power to run could be say chopped nearly in half (a modest number)
to
> > say 50% if it could do more than one instruction per second and most
of
> > the instructions in a decoder are repetitive and take up much of the
cpu
> > time.   Now scale the instructions per second up to current cpus and
you
> > get from a few tens of millions to a few hundred billions.  so now
> > you're down to around 5%.  now add in the improved cache designs and
> > branch prediction and prefetching (not even counting the better
> > motherboard designs that make memory access easier and faster) and i
> > think it's very possible to get down to near zero cpu usage on a
modern
> > day x86 cpu for such repetitive tasks such as decoding.
> >
> > > > From a look at /proc I find that the player threads eat 0.02s of
> user
> > > > time and 0.2s of kernel time per minute of playing, so it is
truly
> > > > 0.3%.  Therefore, if the time calculated is wrong, it is
kernel's
> > > > fault.
> > >
> > > That seems to be the case, (Will we ever find a reliable kernel,
> anyways? ;-) unless the guys hacking xmms have found some miracle way
of
> playing mp3's
> > >
> > > I think other mp3-players (like madplay or mpg123) will yield
values
> more 'in leage' with ogg123. I'll test it someday when I get my hands
om
> my
> linux computer again.
> > >
> > > -Joel
> > >
> > > --- >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.
> > >
> >
> >
> >
> > --- >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.
> >
> 
> 
> --- >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.

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