[tremor] [PATCH] significantly reduce Tremor ROM size requirement

[Nicolas Pitre]

On Thu, 5 Sep 2002, Monty wrote:

> 
> On Wed, Sep 04, 2002 at 08:56:55PM -0400, Nicolas Pitre wrote:
> 
> > However Tremor currently has some drawbacks over my version.  First it is a
> > bit slower.
> 
> There's less assembly in Tremor right now.  However, Tremor avoids a
> number of big buffer copies the FullPlay code did not.  How did you
> evaluate 'a little slower'?  I'd have expected it to be roughly equal
> (and naturally, more of it needs to be optimized/ASM-ized).

Well, say 30% vs 27% CPU usage on some ARM board I have here.  I'm expecting
this difference can be reduced with proper compiler flags though.

> > It also has a much much larger memory footprint.
> 
> It has a much larger text segment, but a much smaller heap footprint.

Well I didn't compare with my hacked up fixed point version.  Better just 
look at what can be improved in Tremor instead.

> In embedded designs, where memory is a concern, heap tends to be a
> much tighter commodity than flash/ROM.  This naturally depends on the
> architecture.

Of course.

> Overall memory usage is about 1/2 - 2/3 of the original fixed point
> port that iObjects did.  The big hit- codebook usage- is less than a
> third of the FullPlay code.

Never saw iObjects code so can't comment.

> >  I don't know
> > how much improvement can be done to the performance yet, but the size issue
> > can be solved and I produced a patch for that.
> 
> This doesn't solve the size issue, it just pushes it to somewhere
> else.  It also increases startup time and requires trigonometry
> approximations I prefer to avoid.

Why so?  AFAICS the accuracy didn't change.

> The final memory usage is the same and now you've also introduced
> additional initialization latency that can contribute to hiccups
> between logical segments.  Not alot, it's true, but it's a bad place
> to be making things slower.

Well if your CPU isn't fast enough to build a couple tables with lookups and 
interpolation you won't sustain a real time decoding of each audio frames 
requiring many more cycles.

> > The idea is to get rid of all those big static arrays in the window and mdct
> > code since all possible configurations are currently statically preallocated
> > and therefore bloating the library text.
> > version of the Vorbis library, without significant CPU usage.  RAM usage
> > will be slightly increased but still be much less than the removed ROM size
> > by an order of magnitude.
> 
> Actually, you've just shifted the order of magnitude.  RAM usage
> increases by the amount of static memory you've eliminated.

Please get real.  Did you _really_ look at actual numbers?

OK, here's the numbers again, with allocated heap size this time.

   text    data     bss     dec     hex filename
  47095  127176    4160  178431   2b8ff ivorbisfile_example.orig
  47735    4892    4160   56787    ddd3 ivorbisfile_example.patched

Typical execution:
Bitstream is 2 channel, 44100Hz
Decoded length: 10204740 samples
Encoded by: Xiphophorus libVorbis I 20011231

ivorbisfile_example.orig:
total allocated space                        = 122336

ivorbisfile_example.patched:
total allocated space                        = 139720

If I can read this right, I've got a 17KB (14%) heap increase for a 119KB
(62%) text reduction.  This is not with the largest window size but not the 
smallest either.  I don't think this can be considered a simple "shift" from 
ram to static memory.

> The proper thing to do here is eliminate the need for most of that
> table entirely, not move it to dynamic allocation.  Currently,
> Tremor's MDCT table contains some easy-to-eliminate redundancy. Some
> harder work would eliminate the table almost entirely.

Well it's easy to keep only one window table and interpolate inside it 
according to the block size too.

But at least for now you could consider this patchlet which shouldn't be 
controversial:

diff -urN orig/Tremor/floor0.c Tremor/floor0.c
--- orig/Tremor/floor0.c	Mon Sep  2 23:15:19 2002
+++ Tremor/floor0.c	Wed Sep  4 16:32:07 2002
@@ -117,21 +118,21 @@
   }
 }
 
-static int MLOOP_1[64]={
+static unsigned char MLOOP_1[64]={
    0,10,11,11, 12,12,12,12, 13,13,13,13, 13,13,13,13,
   14,14,14,14, 14,14,14,14, 14,14,14,14, 14,14,14,14,
   15,15,15,15, 15,15,15,15, 15,15,15,15, 15,15,15,15,
   15,15,15,15, 15,15,15,15, 15,15,15,15, 15,15,15,15,
 };
 
-static int MLOOP_2[64]={
+static unsigned char MLOOP_2[64]={
   0,4,5,5, 6,6,6,6, 7,7,7,7, 7,7,7,7,
   8,8,8,8, 8,8,8,8, 8,8,8,8, 8,8,8,8,
   9,9,9,9, 9,9,9,9, 9,9,9,9, 9,9,9,9,
   9,9,9,9, 9,9,9,9, 9,9,9,9, 9,9,9,9,
 };
 
-static int MLOOP_3[8]={0,1,2,2,3,3,3,3};
+static unsigned char MLOOP_3[8]={0,1,2,2,3,3,3,3};
 
 void vorbis_lsp_to_curve(ogg_int32_t *curve,int *map,int n,int ln,
                          ogg_int32_t *lsp,int m,

<p>Nicolas

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