Re: [RFC] LZO de/compression support - take 6

[Daniel Hazelton <dhazelton@enter.net>]

On Monday 28 May 2007 13:11:15 Adrian Bunk wrote:
> On Mon, May 28, 2007 at 09:33:32PM +0530, Nitin Gupta wrote:
> > On 5/28/07, Adrian Bunk <bunk@stusta.de> wrote:
> >...
> >
> >> - then ensure that it works correctly on all architectures and
> >
> > Already tested on x86, amd64, ppc (by Bret). I do not have machines
> > from other archs available. Bret tested 'take 3' version but no
> > changes were introduced in further revisions that could affect
> > correctness - but still it will be good to have this version tested
> > too. Only with inclusion in -mm and testing by much wider user base
> > can make it to mainline (I suppose nobody uses -mm for production use
> > anyway).
> >
> >>   document why your version is that much faster than the original
> >>   version and why you know your optimizations have no side effects

With likely(), unlikely() and noinline *not* defined as NOP's performance 
drops:

10000 run averages:
'Tiny LZO':
        Combined: 84.9292 usec
        Compression: 42.4646 usec
        Decompression: 42.4646 usec
'miniLZO':
        Combined: 61.3548 usec
        Compression: 43.5648 usec
        Decompression: 17.79 usec

However, I'm worried that my testbed code - likely the Perl script that 
actually loops the test code and collects its output - is somehow faulting, 
as the way that the Compression and Decompression code have the exact same 
value.

I'm going to toss some debugging output in the script and see if I can spot 
the problem.

DRH