From owner-freebsd-bugs@FreeBSD.ORG Sun Jan 20 16:50:52 2008 Return-Path: Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 388E216A417; Sun, 20 Jan 2008 16:50:52 +0000 (UTC) (envelope-from mi@aldan.algebra.com) Received: from romulan2.deckpoint.ch (romulan3.deckpoint.ch [194.38.160.11]) by mx1.freebsd.org (Postfix) with ESMTP id C37C813C44B; Sun, 20 Jan 2008 16:50:51 +0000 (UTC) (envelope-from mi@aldan.algebra.com) Received: from vaio.virtual-estates.net (ppp-69-180-38-194.adsl.deckpoint.net [194.38.180.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by romulan2.deckpoint.ch (DeckMail) with ESMTP id E7EE56CCB51; Sun, 20 Jan 2008 17:51:21 +0100 (CET) Received: from vaio.virtual-estates.net (localhost [127.0.0.1]) by vaio.virtual-estates.net (8.14.2/8.13.7) with ESMTP id m0KGokob020265; Sun, 20 Jan 2008 16:50:47 GMT (envelope-from mi@aldan.algebra.com) Received: from localhost (localhost [[UNIX: localhost]]) by vaio.virtual-estates.net (8.14.2/8.13.7/Submit) id m0KGojvJ020264; Sun, 20 Jan 2008 16:50:45 GMT (envelope-from mi@aldan.algebra.com) X-Authentication-Warning: vaio.virtual-estates.net: mi set sender to mi@aldan.algebra.com using -f From: "Mikhail T." To: David Schultz Date: Sun, 20 Jan 2008 16:50:44 +0000 User-Agent: KMail/1.9.7 References: <200707051510.l65FAAEp090370@freefall.freebsd.org> <200801200951.29254@Misha> <20080120122945.GC2613@VARK.MIT.EDU> In-Reply-To: <20080120122945.GC2613@VARK.MIT.EDU> X-Face: %UW#n0|w>ydeGt/b@1-.UFP=K^~-:0f#O:D7whJ5G_<5143Bb3kOIs9XpX+"V+~$adGP:J|SLieM31VIhqXeLBli"<=?utf-8?q?kcG=5EEOVihy+z3/UR=7B6SCQ=0A?= MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200801201650.45547@Misha> Cc: freebsd-bugs@freebsd.org Subject: Re: bin/96393: [libz] [patch] assembler implementations for libz on i386 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jan 2008 16:50:52 -0000 =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