[Ffmpeg-devel] [PATCH] simple internal lzo decoder

[Jindrich Makovicka]

Reimar D?ffinger wrote:
> Hi,
> On Sun, Jan 15, 2006 at 09:39:46PM +0100, Jindrich Makovicka wrote:
> 
>>Reimar D?ffinger wrote:
>>
>>>file all zeroes, 56325B comp:
>>>8.90 8.90 0.80 8.87 8.46 0.75
>>
>>I am getting ~3.1s here for minilzo and ~1.7s for av-lzo on XP-M
>>2600+ at 2.1GHz. Either I am doing something totally wrong or minilzo just
>>sucks on 64-bit machines. I was using gcc-3.4, patched lzo.c and
>>lzo1x_decompress_safe from minilzo to be fair.
> 
> 
> Yes, I used basically the same, but used the _999_ compression function.
> Resulting file is here: http://www.stud.uni-karlsruhe.de/~uvhe/comp2.lzo
> Maybe that makes a difference.
> But two much more likely effects: I was running @800MHz, but your times
> are higher. Maybe your libc sucks :-)? On 64 bit systems they can
> optimize it far more. Also, minlzo uses a loop to copy, maybe it uses a
> normal int as counter, so additional code is needed between the increment
> and address index operation to convert between 32 and 64 bits.

I am using debian's 686 libc, so it should be ok. But it is possible,
that with 800MHz CPU the decompression is more cpu-bound, while it is
more memory bound on my machine. By the way, the

    dst[0] = src[0];
    dst[1] = src[1];
    dst[2] = src[2];
    dst[3] = src[3];

style sequences compile to eight byte-wise instructions with gcc 3.4 and
gcc 4.0.3. So maybe replacing them with
*((uint32_t*)dst)=*((uint32_t*)src) or 64-bit equivalent can gain some
more speed if the process is cpu bound. However it didn't make any
difference for me, which suggests that memory latency is the bottleneck
rather than the cpu.

-- 
Jindrich Makovicka