Hi all,
First regarding mutexes on Macs, I suppose a performance hit with mutexes beats
no performance at all with missing spinlocks. And regarding "take more work," I
believe spinlocks and mutexes were basically interchangeable in terms
of functionality
in our sort algorithm; the work probably wi
On Mon, Jul 26, 2010 at 11:53 AM, Paul Eggert wrote:
> I noticed thirteen "inline"s in coreutils/src/sort.c. Just for fun, I
> removed them all. In ten cases, removing "inline" made no difference to
> the generated machine code on my platform (RHEL 5, x86-64, GCC 4.1.2,
> compiled with the typic
On Sun, Jul 11, 2010 at 5:06 AM, Bruno Haible wrote:
> Hi Paul,
>
> There is one API bug and two oddities in your patch:
> 2) You added documentation to memcoll0 that does not make references to other
> functions. Good. Can we have the same for xmemcoll0 as well?
>
> 3) There are two 'const char
Hi Padraig,
> From: Pádraig Brady
> To: Bruno Haible
> Cc: Chen Guo ; bug-gnulib@gnu.org
> Sent: Wed, April 21, 2010 1:46:47 AM
> Subject: Re: [PATCH] (x)memcoll: performance improvement when input is known
> to be NUL delimited.
>
> On 14/03/10 14:24, Bruno
Hi Padraig,
Thanks for the _unlikely insight, that explains why it's not slower
but the speed up is still quite mysterious. When I ran with the line
lengths you wanted, with check it is no longer faster, but something
else I don't quite understand pops up.
The file I usually test on is 1M
luded
in memcoll.c instead, since that's what xmemcoll.c includes.
>From 19516c730bced56670d180899d099e18be2a9ae3 Mon Sep 17 00:00:00 2001
From: Chen Guo
Date: Sun, 7 Mar 2010 17:07:49 -0800
Subject: [PATCH] (x)memcoll: performance improvement when input is known to be
NUL delimited.
Thi
Hi Bruno,
I'm going through and applying your suggestions, and I'm a bit iffy on this
one:
> > +/* Like memcoll, but S1 and S2 are known to be NUL delimited, thus no
> > + modification to S1 or S2 are needed. */
> > +int
> > +memcoll_nul (char *s1, size_t s1len, char *s2, size_t s2len)
> >
Hi Bruno,
I'll make all the changes you proposed, except this I have some questions
about:
> For each input line, xmemcoll is called multiple times? Then you can certainly
> gain much more speed than 1% by replacing memcoll with 2 x memxfrm and
> 1 x memcmp2. Of course, the 'sort' program w
001
From: Chen Guo
Date: Sun, 7 Mar 2010 17:07:49 -0800
Subject: [PATCH] (x)memcoll: performance improvement when input is known to be
NUL delimited.
This is in suport of a patch to coreutils' sort, where for each
input line xmemcoll is called several times. If each input line is
NUL delimi
Hi all,
I'm submitting a performance patch to sort soon that requires this for one
of the patch's smaller optimizations, but hey, 1% is 1%.
nul_patch
Description: Binary data
10 matches
Mail list logo
