Date: Sun, 20 Jan 2008 16:50:44 +0000 From: "Mikhail T." <mi@aldan.algebra.com> To: David Schultz <das@freebsd.org> Cc: freebsd-bugs@freebsd.org Subject: Re: bin/96393: [libz] [patch] assembler implementations for libz on i386 Message-ID: <200801201650.45547@Misha> In-Reply-To: <20080120122945.GC2613@VARK.MIT.EDU> References: <200707051510.l65FAAEp090370@freefall.freebsd.org> <200801200951.29254@Misha> <20080120122945.GC2613@VARK.MIT.EDU>
index | next in thread | previous in thread | raw e-mail
неділя 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. It would not be without precedent and the libz's build procedure (which we are not using) allows for it -- we don't even need to modify the "vendor's branch". 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. Yes, port is a possibility and something I can do myself, but "out-of-the-box" performance improvement seems a worthy goal to me. Libz is not a port, but part of the src-tree -- offering to replace it with a "better libz" (of the same version!) begs the question of why it is not done by default... -mihelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200801201650.45547>