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

[Alen Ladavac]

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?

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

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