linux-kernel - Re: [RFC] LZO de/compression support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 26 May 2007 01:05:41 +0530
From:	"Satyam Sharma" <satyam.sharma@...il.com>
To:	"Daniel Hazelton" <dhazelton@...er.net>
Cc:	"Richard Purdie" <richard@...nedhand.com>,
	"Nitin Gupta" <nitingupta910@...il.com>,
	linux-kernel@...r.kernel.org, linux-mm-cc@...top.org,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Andrey Panin" <pazke@...pac.ru>, "Bret Towe" <magnade@...il.com>,
	"Michael-Luke Jones" <mlj28@....ac.uk>
Subject: Re: [RFC] LZO de/compression support - take 4

Hi Daniel,

On 5/26/07, Daniel Hazelton <dhazelton@...er.net> wrote:
> On Friday 25 May 2007 12:55:21 Daniel Hazelton wrote:
> <snip>
> > As to the performance - I can see absolutely no reason why the minimal
> > version shouldn't perform the same (or better). The kernel codes memset and
> > memcpy routines have been heavily tested *and* optimized over the years and
> > moving from macro's to inline functions shouldn't have impacted performance
> > at all. I will be testing the two code bases myself in a little bit - I'm
> > more than a little paranoid and don't like the idea of trusting anyone with
> > a "competing project" for all testing.
>
>
> I'll have to better instrument my test code (a real quick (userspace) hack)
> using the minimized LZO1X implementation (take 4 :) and the complete LZOv2
> library (lzo1x_1_11_compress and the *unsafe* version of the decompressor
> used) but preliminary testing using just "time ./test" - the differences I've
> seen might be because I'm directly including one version of the code and the
> other is in a shared library. But even if I discount the system and user
> time - going *only* by the "real" time value I get results across 10 runs
> that differ by less than 0.001s - the average across 10 runs of the stripped
> down LZO code is about 0.00133s where the LZO library (liblzo2) returns about
> even performance - average is 0.001s.
>
> A total difference of *ONE* *THIRD* of *ONE* *THOUSANDTH* of a second. With
> the better performance being in-kernel should bring, I can see no reason for
> a "big" difference.
>
> If anyone's interested in the code I used for the test, let me know and I'll
> make it available.

Yes, please do. It'd be nice if numbers are compared across arch's (LE,
BE, 32-bit, 64-bit) by others who have access to such boxes too.

Thanks,
Satyam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/