[Numpy-discussion] String sort

Francesc Altet faltet at carabos.com
Thu Feb 14 11:11:33 EST 2008


A Wednesday 13 February 2008, Charles R Harris escrigué:
> On Feb 13, 2008 10:56 AM, Francesc Altet <faltet at carabos.com> wrote:
> > Be warned, I'd like to stress out that these are my figures for my
> > _own laptop_.  It would be nice if you can verify all of this with
> > other achitectures (your Core2 machine seems different enough).  I
> > can run the benchmarks on Windows (installed in the same laptop)
> > too.  Tell me if you are interested on me doing this.
>
> Its easy enough to test if you compile from svn, just add your new
> copy function and change the name in this line:
>
>    #copy=copy_string, copy_ucs4#
>
> to use your function instead of copy_string.

I've spoken too fast.  I've never compiled NumPy on Windows before, and 
had problems when trying to compile it using MSVC 7.1 and a recent copy 
of the repository.  Well, in any case, I've exercised the Opteron 
platform, using gcc 4.1.3 (i.e. the one that can optimize newqsort 
correctly), and this brings new light to our study.

From the plot (attached), it can be drawn the next conclusions:

1) copy_string2 (the combination of manual copy and memcpy) is not 
better than memcpy for *any* value of the string length in our Opteron 
platform.  Also, the improvements with Pentium4 was not that big 
(<20%).  In consequence, I'd choose to always use memcpy and discard 
copy_string2.

2) Curiously enough, the indirect sort in Opterons is *always* faster 
than newqsort+memcpy.  For large values of string lengths (> 256), the 
speed-up can be up to 3x, which is a lot.  And I'd say that this keeps 
true also for most modern processors (read Core2, Barcelona).  For older 
processors (Pentium4), the indirect method can be slower than direct 
plot for small lengths, but by a very few extent (<10%).

Conclusion 2 makes me wonder if it wouldn't be useful the introduction 
of a new flag in sort, like:

"""
`indirect` - Use the indirect method for sorting.  This requires more 
memory (4/8 bytes per array element), but for sorting arrays of strings 
it is almost always faster than the direct approach (default). Beware: 
this is not the case when using numerical values, where the use of this 
method for sorting is not recommendable.
"""

Agreed, that could introduce some confusion, but as this flag would 
be 'False' by default, not many people should bother about its 
existence, and can definitely help to people who cares about sorting 
string performance.

Cheers,

-- 
>0,0<   Francesc Altet     http://www.carabos.com/
V   V   Cárabos Coop. V.   Enjoy Data
 "-"

-------------------------------------------------------

-- 
>0,0<   Francesc Altet     http://www.carabos.com/
V   V   Cárabos Coop. V.   Enjoy Data
 "-"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: suse-opteron-newqsort.pdf
Type: application/pdf
Size: 20365 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20080214/19717ac1/attachment.pdf>


More information about the NumPy-Discussion mailing list