From unknown Mon Aug 11 18:18:58 2025 X-Loop: help-debbugs@gnu.org Subject: bug#6804: Bug-coreutils Digest, Vol 93, Issue 6 Resent-From: Lars Ole Belhage Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Thu, 05 Aug 2010 20:09:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 6804 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: 6804@debbugs.gnu.org X-Debbugs-Original-To: bug-coreutils@gnu.org Reply-To: belhage@midibel.com Received: via spool by submit@debbugs.gnu.org id=B.128103892020528 (code B ref -1); Thu, 05 Aug 2010 20:09:01 +0000 Received: (at submit) by debbugs.gnu.org; 5 Aug 2010 20:08:40 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oh6k3-0005Kz-AI for submit@debbugs.gnu.org; Thu, 05 Aug 2010 16:08:40 -0400 Received: from mx10.gnu.org ([199.232.76.166]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oh4fj-0004On-Me for submit@debbugs.gnu.org; Thu, 05 Aug 2010 13:56:04 -0400 Received: from lists.gnu.org ([199.232.76.165]:45461) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Oh4gF-000316-AO for submit@debbugs.gnu.org; Thu, 05 Aug 2010 13:56:35 -0400 Received: from [140.186.70.92] (port=33044 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Oh4gD-0000MY-OA for bug-coreutils@gnu.org; Thu, 05 Aug 2010 13:56:34 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,RDNS_DYNAMIC, TO_NO_BRKTS_DYNIP autolearn=no version=3.3.1 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Oh4gC-0008Es-4B for bug-coreutils@gnu.org; Thu, 05 Aug 2010 13:56:33 -0400 Received: from cpe.atm2-0-1111017.boanxx15.customer.tele.dk ([80.163.197.14]:1838 helo=lobnet.dk) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oh4gB-0008Dq-OJ for bug-coreutils@gnu.org; Thu, 05 Aug 2010 13:56:32 -0400 Received: from [89.10.1.44] (dp64 [89.10.1.44]) by lobnet.dk (8.12.8/8.12.8) with ESMTP id o75HwUXv002789 for ; Thu, 5 Aug 2010 19:58:30 +0200 From: Lars Ole Belhage In-Reply-To: <201008051722.o75HMHXv002091@lobnet.dk> References: <201008051722.o75HMHXv002091@lobnet.dk> Content-Type: text/plain Organization: MidiBel Date: Thu, 05 Aug 2010 19:56:21 +0200 Message-Id: <1281030981.6327.14.camel@dp64> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-10.fc7) Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4-2.6 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-Spam-Score: -6.6 (------) X-Mailman-Approved-At: Thu, 05 Aug 2010 16:08:36 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.6 (------) On Thu, 2010-08-05 at 12:03 -0400, bug-coreutils-request@gnu.org wrote: > Send Bug-coreutils mailing list submissions to > bug-coreutils@gnu.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.gnu.org/mailman/listinfo/bug-coreutils > or, via email, send a message with subject or body 'help' to > bug-coreutils-request@gnu.org > > You can reach the person managing the list at > bug-coreutils-owner@gnu.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Bug-coreutils digest..." > > > Today's Topics: > > 1. bug#6789: propose renaming gnulib memxfrm to amemxfrm (naming > collision with coreutils) (Paul Eggert) > 2. bug#6789: propose renaming gnulib memxfrm to amemxfrm (naming > collision with coreutils) (Simon Josefsson) > 3. bug#6789: propose renaming gnulib memxfrm to amemxfrm (naming > collision with coreutils) (Paolo Bonzini) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 04 Aug 2010 16:21:28 -0700 > From: Paul Eggert > Subject: bug#6789: propose renaming gnulib memxfrm to amemxfrm (naming > collision with coreutils) > To: Bruno Haible > Cc: Bug-gnulib , Bug-coreutils > > Message-ID: <4C59F5F8.9080309@cs.ucla.edu> > Content-Type: text/plain; charset=UTF-8 > > On 08/03/10 16:33, Bruno Haible wrote: > > But when the stack buffer is not sufficient, then the use of coreutils memxfrm > > is 30% to 70% slower than the use of gnulib memxfrm, with a difference of > > 700 sec at least. > > (Ooo! Ooo! Performance measurements! I love this stuff!) > > It depends on the data. In the typical case, "sort" is applied to > text data, which does not contain NUL bytes. The data in that > benchmark contained many NUL bytes. If you take the same benchmark > and uniformly replace "\0" with "\t" in compare.c, then the situation > is much different: coreutils memxfrm is about 3 times faster than > gnulib memxfrm on the larger test cases (this platform is Ubuntu > 10.04, gcc 4.5.0, 2.4 GHz Pentium 4): > > 503-penguin $ gcc -std=gnu99 -O2 -Wall coreutils-memxfrm.c gnulib-memxfrm.c compare1.c -I. > 504-penguin $ ./a.out > Time for gnulib_memxfrm: 0,032002 > Time for coreutils_memxfrm: 0,028001 > Time for gnulib_memxfrm: 0,024002 > Time for coreutils_memxfrm: 0,024001 > Time for gnulib_memxfrm: 0,036003 > Time for coreutils_memxfrm: 0,032002 > Time for gnulib_memxfrm: 18,2051 > Time for coreutils_memxfrm: 5,48834 > Time for gnulib_memxfrm: 16,045 > Time for coreutils_memxfrm: 5,50034 > Time for gnulib_memxfrm: 15,837 > Time for coreutils_memxfrm: 5,44834 > > I expect that this performance glitch in gnulib memxfrm could be > improved, as it shouldn't simply double buffer sizes when they're too > small, as at that point it already knows what the final buffer size > should be. Doing this should bring up gnulib memxfrm to be as fast as > coreutils xmemxfrm for this benchmark. Also, I agree that gnulib > memxfrm is faster in some important cases. Still, gnulib memxfrm is > problematic, because it insists on managing memory itself. > > Come to think of it, looking at gnulib memxfrm gave me an idea > to improve the performance of GNU sort by bypassing the need for an > memxfrm-like function entirely. I pushed a patch to do that at > . > > This avoids any potential naming collision for now. The point > remains, though, that it's confusing that gnulib memxfrm's name begins > with "mem", as the mem* functions don't allocate memory. Would you > consider a patch that renames gnulib memxfrm to amemxfrm, or to some > other such name? > > > > > > > ------------------------------ > > Message: 2 > Date: Thu, 05 Aug 2010 01:44:30 +0200 > From: Simon Josefsson > Subject: bug#6789: propose renaming gnulib memxfrm to amemxfrm (naming > collision with coreutils) > To: Paul Eggert > Cc: Bug-gnulib , Bug-coreutils > , Bruno Haible > Message-ID: <8739uurli9.fsf@mocca.josefsson.org> > Content-Type: text/plain; charset=us-ascii > > Paul Eggert writes: > > > Come to think of it, looking at gnulib memxfrm gave me an idea > > to improve the performance of GNU sort by bypassing the need for an > > memxfrm-like function entirely. I pushed a patch to do that at > > . > > I don't know this code at all, but would your approach lead to problems > if two different strings have the same MD5 hash? MD5 is broken, and > finding collisions takes just seconds on normal PC. See: > http://en.wikipedia.org/wiki/MD5#Security > > /Simon > > > > > > ------------------------------ > > Message: 3 > Date: Thu, 05 Aug 2010 04:58:26 +0200 > From: Paolo Bonzini > Subject: bug#6789: propose renaming gnulib memxfrm to amemxfrm (naming > collision with coreutils) > To: bug-gnulib@gnu.org, Bug-coreutils , Paul > Eggert > Message-ID: <4C5A28D2.3040102@gnu.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 08/05/2010 01:44 AM, Simon Josefsson wrote: > > Paul Eggert writes: > > > >> Come to think of it, looking at gnulib memxfrm gave me an idea > >> to improve the performance of GNU sort by bypassing the need for an > >> memxfrm-like function entirely. I pushed a patch to do that at > >> . > > > > I don't know this code at all, but would your approach lead to problems > > if two different strings have the same MD5 hash? MD5 is broken, and > > finding collisions takes just seconds on normal PC. See: > > http://en.wikipedia.org/wiki/MD5#Security > > MD5 is used simply as a kind of "random key generator", so it doesn't > matter. I wonder two things however: > > 1) why bother with memxfrm as a tie-breaker? isn't memcmp good enough? > > 2) maybe there's something cheaper than md5 that can be used? For > example you could compare a^x and b^x where x is the output of a fast > 32-bit random number generator? It doesn't need to be cryptographic, > I'd pick http://en.wikipedia.org/wiki/Xorshift. > > Paolo > > > > > > ------------------------------ > > _______________________________________________ > Bug-coreutils mailing list > Bug-coreutils@gnu.org > http://lists.gnu.org/mailman/listinfo/bug-coreutils > > > End of Bug-coreutils Digest, Vol 93, Issue 6 > ******************************************** From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 25 01:44:58 2011 Received: (at control) by debbugs.gnu.org; 25 Aug 2011 05:44:58 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QwSkL-0003v2-Ld for submit@debbugs.gnu.org; Thu, 25 Aug 2011 01:44:57 -0400 Received: from joseki.proulx.com ([216.17.153.58]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QwSkK-0003uw-I8 for control@debbugs.gnu.org; Thu, 25 Aug 2011 01:44:56 -0400 Received: from hysteria.proulx.com (hysteria.proulx.com [192.168.230.119]) by joseki.proulx.com (Postfix) with ESMTP id 215D021419 for ; Wed, 24 Aug 2011 23:42:19 -0600 (MDT) Received: by hysteria.proulx.com (Postfix, from userid 1000) id 08E8D49912; Wed, 24 Aug 2011 23:42:19 -0600 (MDT) Date: Wed, 24 Aug 2011 23:42:19 -0600 From: Bob Proulx To: control@debbugs.gnu.org Subject: closing 6804 Message-ID: <20110825054219.GA28692@hysteria.proulx.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Score: -2.5 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.5 (--) close 6804 thanks It has been a year since this bug was submitted. And it isn't even a bug but simply a misdirected digest posting. Cleaning.