From owner-freebsd-bugs@FreeBSD.ORG Mon Jan 28 06:29:44 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 A21C116A417 for ; Mon, 28 Jan 2008 06:29:44 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.freebsd.org (Postfix) with ESMTP id 66E1713C448 for ; Mon, 28 Jan 2008 06:29:44 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.14.2/8.14.1) with ESMTP id m0S6Thln082171; Mon, 28 Jan 2008 01:29:43 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.14.2/8.14.1/Submit) id m0S6Thom082170; Mon, 28 Jan 2008 01:29:43 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Mon, 28 Jan 2008 01:29:43 -0500 From: David Schultz To: "Mikhail T." Message-ID: <20080128062943.GA82037@VARK.MIT.EDU> Mail-Followup-To: "Mikhail T." , freebsd-bugs@FreeBSD.ORG References: <200707051510.l65FAAEp090370@freefall.freebsd.org> <200801200951.29254@Misha> <20080120122945.GC2613@VARK.MIT.EDU> <200801201650.45547@Misha> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <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: Mon, 28 Jan 2008 06:29:44 -0000 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.