lzo2 shows insane speed gap

[Nate Eldredge]

On Mon, 29 Dec 2008, Christian Weisgerber wrote:

> The archivers/lzo2 port runs a series of regression tests after the
> actual build.  These tests show extremely divergent behavior on
> different machines.  There are two types of machines:
>
> Type #1:
>  Running the tests takes roughly the same time as configure and
>  compile did, whether it's 30 seconds on a fast machine or 10
>  minutes on an old slow one.
>
> Type #2:
>  Running the tests takes much, much, MUCH longer.
>
> I've tried this across alpha, amd64, i386, and sparc64, partially
> on FreeBSD, partially on OpenBSD.  The operating system doesn't
> matter and there is no pattern related to endianness or 32/64 bits.
>
> You can find machines that are the same architecture (e.g. amd64)
> and are of similar overall speed (e.g. an Intel Xeon Xeon E5405 and
> an AMD Phenom 9350e) and one of these machines will be type #1 and
> the other will be #2 and take _a hundred_ times longer to run the
> tests.  A hundred times.
>
> I have never seen anything like this before.

It might be good first to rule out compiler / library differences.

First, can you isolate a single lzo command / input combination whose time 
differs dramatically?  This would simplify tests compared to running the 
whole test suite.  (It should be easy because it looks like the test suite 
prints the time for each test.)  It might also simplify things to work on 
one "fast" and one "slow" machine.

Then try copying the lzo binary from the "fast" machine to the "slow" 
machine (and vice versa) and see if the same test speeds up with the 
copied binary.  If not, try again with the binary statically linked.  If 
still not, it would be good to have a copy of the binary made available, 
along with more information about the "fast" and "slow" machines (CPU, 
amount of memory, load on the machine, kernel version, disk, etc).

If the copied binary isn't faster than the natively produced one, then it 
would be good to have information about the compiler options, versions, 
etc.

-- 

Nate Eldredge
neldredge at math.ucsd.edu