[Zlib-devel] update for zlib 1.2.3.9 - project and assembly code

[Gilles Vollant]

I made a test on mac osx x86_64
- 9400 msec in pure C code, 8850 with ald64-match.S
run test several time. I ve the same kind of result with several file (often
between 8% and 15% of acceleration)
As I remember Visual C++ test, result are same. But I don't made bench
against new Visual Studio 2010 Release candidate with profile guided
optimization enabled.

about the licence scheme : for my work, I just want the same zlib licence
anything like "use it, just don't say you done with without mention me"
as I understand, all people who made asm work on alib have same idea
if I can change anything to help you using it...

there was a bug in gvmat64.asm before zlib1.2.3.8. It is now fixed, and the
zipfile below contain also the fix on the amd64-match.S version. 

I'm now very confident in reliability of current longest_match for x86_64
(both gvmat64.asm and amd64-match.S). But of course, test are welcome... :-)


amd64-match.S is more or less a translation of gvmat64.asm to GCC syntax,
with an optional SSE option (disabled by default, and which don't
accelerate)

-----Message d'origine-----
De : zlib-devel-bounces at madler.net [mailto:zlib-devel-bounces at madler.net] De
la part de Xin LI
Envoyé : mardi 23 février 2010 23:51
À : zlib-devel at madler.net
Cc : zlib-devel at zlib.net; Mark Adler
Objet : Re: [Zlib-devel] update for zlib 1.2.3.9 - project and assembly code

On Tue, Feb 23, 2010 at 2:16 PM, Gilles Vollant <info at winimage.com> wrote:
>
>
>
> http://gvollant.free.fr/upd2gv_zlib1239.zip
>
> contain:
>
> example.c : add printing of deflate_state offset used by assembly
> longest_match (remove if you don't want it)
> contrib/amd64/amd64-match.S : now use by default the good offset for GCC
on
> linux and macosx x86_64
> my yesterday fix on the SSE2 portion is also modified to be faster
>
> contrib/masmx64/inffas8664.c : an inflate_state member was renamed (write
> become wnext)
> contrib/vstudio/vc9 and contrib/vstudio/vc10 : minor update
>
> I suggest remove vc7 and vc8
>
>
> Just a question now : how many people use the assembly code version (for
x86
> and x86_64)
> if not, why ?
> - not interested by more performance
> - not sure the code is reliable
> - complex integration

We (FreeBSD) are not currently using the assembly code version mainly
due to licensing issue (the code for amd64 uses a different license as
contrary to 686 asm).  If I remember correctly the amd64 version has
caused some crash during my test which I didn't get a chance to
investigate further yet.  I am personally very interested in
integrating the assembly code on FreeBSD if performance test shows
some gains and no regression.

Cheers,
-- 
Xin LI <delphij at delphij.net> http://www.delphij.net