<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1491" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial><PRE><FONT size=2></FONT>&nbsp;</PRE><PRE><FONT size=2>Hi,</FONT></PRE><PRE><FONT size=2>I understand about this mips calculation but i surprise that evenif </FONT></PRE><PRE><FONT size=2>we make the 1st call static these cycles will contribute as the worst case figure.</FONT></PRE><PRE><FONT size=2>So I started optimizing some intitialization routines to reduce the 1st frame mips.</FONT></PRE><PRE><FONT size=2>Is it the correct step?</FONT></PRE><PRE><FONT size=2>With regards,</FONT></PRE><PRE><FONT size=2>Madhav Kulkarni</FONT></PRE><PRE><FONT size=2>======================================================================================</FONT></PRE><PRE><FONT size=2>Hi,

The MIPS calculation is correct but I think there are some points that
need to be considered:-

1. The first call to ov_read always will be more than that for an
actual worst case. In such a case, what I suggest is the first call to
ov_read be placed outside the loop and counted as the static cycles
required for header initialization and not in the MCPS calculation.
Anyways only difference as you may have seen is that in the first
frame the memory initialization and table generation for huffman(I
suppose) are done.

2. For an audio signal, the method of calculating MCPS as you describe
can not be justified. A simplistic approach is to have the cycles
taken to decode fs*nChannel number of samples. This can be achieved by
adding up the cycles for each call to ov_read until the total number
of samples just exceeds or is equal to the product fs*nChannel.

Eg. For the situation you present nChannel*fs = 44100*1 = 44100 samples.

say cycles for 44192 samples is got as x cycles, so MCPS is now given by :-

MCPS = (x/44192)*0.044100

The worst case needs to be evaluated for such a case now.

You may need to evaluate the criterion on a large test set as such a
measure is highly dependent on the test vector used.

3. Another highly lose way to evaluate the MCPS is the average method.
You may add up cycles for the entire song length. And then evaluate
the MCPS by the same logic. This method may not be a recomended one.

Hope this helps...
Rip

On Thu, 03 Mar 2005 12:12:56 +0530, madhav kulkarni
&lt;</FONT><A href="http://lists.xiph.org/mailman/listinfo/tremor"><FONT size=2>mpk_india at hotmail.com</FONT></A><FONT size=2>&gt; wrote:
&gt;</FONT><FONT size=2><I> Hi all,
</I>&gt;</FONT><FONT size=2><I> 
</I>&gt;</FONT><FONT size=2><I> I have some problem regarding the mips calculation of the tremor-fixed point
</I>&gt;</FONT><FONT size=2><I> version of ogg-vorbis audio decoder. Can any one look in to this?
</I>&gt;</FONT><FONT size=2><I> 
</I>&gt;</FONT><FONT size=2><I> I have done the profiling for the ogg-vorbis decoder for 1st 10 frames and
</I>&gt;</FONT><FONT size=2><I> observed that cycles taken by ov_read function is as follows:
</I>&gt;</FONT><FONT size=2><I> 1. 1 st frame takes 5,498,613 cycles on the arm9 platform.
</I>&gt;</FONT><FONT size=2><I> 2. 2nd frame onwards this code takes 555,647 cycles on the arm9 platform.
</I>&gt;</FONT><FONT size=2><I> 
</I>&gt;</FONT><FONT size=2><I> I have few questions related to this. I want to compute the mips for these
</I>&gt;</FONT><FONT size=2><I> cycles I get.
</I>&gt;</FONT><FONT size=2><I> 
</I>&gt;</FONT><FONT size=2><I> MIPS taken by ov_read function = ((cycles taken by ov_read function / 4096)
</I>&gt;</FONT><FONT size=2><I> * 44100) / 1,000,000
</I>&gt;</FONT><FONT size=2><I> 
</I>&gt;</FONT><FONT size=2><I> 1. for 1st frame MIPS = ((5,498,613/4096) * 44100) / 1,000,000 = 59.2 MIPS
</I>&gt;</FONT><FONT size=2><I> 2. for 2nd frame onward MIPS = ((555,647/4096) * 44100) / 1,000,000 = 5.98
</I>&gt;</FONT><FONT size=2><I> MIPS
</I>&gt;</FONT><FONT size=2><I> 
</I>&gt;</FONT><FONT size=2><I> 1st thing
</I>&gt;</FONT><FONT size=2><I> 
</I>&gt;</FONT><FONT size=2><I> Now i don't understand is this mips calculation correct? According my
</I>&gt;</FONT><FONT size=2><I> klnowledge i think i have applied the correct formulae for mips comutation.
</I>&gt;</FONT><FONT size=2><I> Is there any mistake in this formulae? Can anyone tell me?
</I>&gt;</FONT><FONT size=2><I> 
</I>&gt;</FONT><FONT size=2><I> 2nd thing
</I>&gt;</FONT><FONT size=2><I> 
</I>&gt;</FONT><FONT size=2><I> 1st frame takes much cycles due to
</I>&gt;</FONT><FONT size=2><I> 1. _make_decode_ready () which is memroy initialization and alocation &amp;
</I>&gt;</FONT><FONT size=2><I> 2.  mdct_backward is called 4 times.
</I>&gt;</FONT><FONT size=2><I> 
</I>&gt;</FONT><FONT size=2><I> 2nd frame onward mdct is called 2 times and length of mdct for these call is
</I>&gt;</FONT><FONT size=2><I> 256 or sometime 2048.
</I>&gt;</FONT><FONT size=2><I> Why it is so?
</I>&gt;</FONT><FONT size=2><I> 
</I>&gt;</FONT><FONT size=2><I> MIPS for any codec is estimated as the worst case. So here worst case is 1st
</I>&gt;</FONT><FONT size=2><I> frame. Can anyone tell, Is this assumption correct to consider the 1st frame
</I>&gt;</FONT><FONT size=2><I> cycles to estimate tremor ogg-vorbis decoder worst count?
</I>&gt;</FONT><FONT size=2><I> 
</I>&gt;</FONT><FONT size=2><I> With Best Regards,
</I>&gt;</FONT><FONT size=2><I> 
</I>&gt;</FONT><FONT size=2><I> Madhav Kulkarni
</I>&gt;</FONT><FONT size=2><I> 
</I>--
</FONT></PRE><!--endarticle--></FONT></DIV></BODY></HTML>