bin/96393: [libz] [patch] assembler implementations for libz on i386

[David Schultz]

On Sun, Jan 20, 2008, Mikhail T. wrote:
> неділя 20 січень 2008, David Schultz, Ви написали:
> = Hmm, sorry, but I don't think we should be in the business of
> = supporting complex optimizations to vendor code that the vendor
> = himself won't support. It would take a substantial amount of
> = effort to verify that the changes are (a) correct and (b) faster,
> = and things could break in subsequent imports.
> 
> Well, we've done it with gzip itself (when it was a standalone executable, 
> rather than libz's client). We are doing it with Sun's msun.

Our msun is based on Sun fdlibm, which is incomplete, and has not
been maintained by the vendor in over 15 years. In contrast, we do
a new libz import every few years.

> The savings are substantial, but they require changes to the build process, 
> which is something, the vendor (a single person, really) is understandibly 
> hesitant to undertake.

It's not just whether it's faster, it's whether people care enough
about the speed of libz that they are willing to risk more bugs,
more security problems, and more merge headaches, for those extra
cycles. Some of these reasons are probably among the objections
the vendor gave you. :) Another catch is that clever assembly
routines often work well for some processors, but in the long run
compilers do better by keeping up with the technology changes. If
you really have your heart set on this, I'd take it up with
someone like des@, who did the last import, since he will have to
deal with any conflicts and other surprises on the next import.