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>
next in thread | previous in thread | raw e-mail | index | archive | help
=D0=BD=D0=B5=D0=B4=D1=96=D0=BB=D1=8F 20 =D1=81=D1=96=D1=87=D0=B5=D0=BD=D1= =8C 2008, David Schultz, =D0=92=D0=B8 =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0= =D0=BB=D0=B8: =3D Hmm, sorry, but I don't think we should be in the business of =3D supporting complex optimizations to vendor code that the vendor =3D himself won't support. It would take a substantial amount of =3D effort to verify that the changes are (a) correct and (b) faster, =3D and things could break in subsequent imports. Well, we've done it with gzip itself (when it was a standalone executable,= =20 rather than libz's client). We are doing it with Sun's msun. It would not b= e=20 without precedent and the libz's build procedure (which we are not using)=20 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,= =20 which is something, the vendor (a single person, really) is understandibly= =20 hesitant to undertake. Yes, port is a possibility and something I can do myself, but "out-of-the-b= ox"=20 performance improvement seems a worthy goal to me. Libz is not a port, but= =20 part of the src-tree -- offering to replace it with a "better libz" (of the= =20 same version!) begs the question of why it is not done by default... -mi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200801201650.45547>