Subject: Re: [boost] Proposed templated integer_sort
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2009-01-14 12:55:36
Steven Ross wrote:
> algorithm_sorting.tar.gz is now in the boost vault, and is formatted for
> I'd appreciate it if people could test it on their compiler and give me some
> It's not quite ready for formal review yet; I'd like a test on MSVC++ first.
The tests pass with msvc 8.0 express and msvc 9.0 express.
>> If you have
>> run mytest.cpp ;
>> (e.g.) in the Jamfile
>> you can run this test with
>> bjam mytest
> Thanks. I'd already tried bjam, but what I figured out is that a link
> /usr/bin/ld: unknown flag: --start-group
> is preventing the executable from being built, so the tests don't run.
> So instead I link the .o file that it was built by bjam, run it, and it runs
> my tests.
This ought to just work. I presume that you are using gcc. What OS?
> 1) I have a perl tuning/regression script that I've used to verify
> performance, and tune some tuning constants.
> One of these tuning constants (MAX_SPLITS) has a 10+% impact on performance,
> because it impacts cache misses and how many recursive stages are executed.
> 10-12 is the range of ideal values for MAX_SPLITS on Intel Processors, and
> 10-11 is ideal on my
> old Motorola PowerPC processor. The penalty for too large a value is
> prohibitive (20+%),
> where the penalty for a value 1 too small is generally less than 10%.
> Based upon that, picking a value of 10 or 11 should be decent across most
> For ideal performance, this should probably be configured to the processor
> it is run on.
> The other 3 constants have much less impact and can reasonably have the same
> across all systems.
> Should I include the tune.pl script with the library (and if so, where,
> or should I do all the performance tuning myself?
If you include it, it should go under libs. My inclination would be to
include the script even if you do have good default values.
> 2) Should I have a separate constants.hpp to contain these constants (as
> or define them directly in the spreadsort.hpp source file?
> If I define them directly in the source file, tune.pl won't work, but it
> makes it easier
> for users to just copy spreadsort.hpp on its own.
I would go for the separate header, but it's up to you.
> 3) Should I use configuration information to set the constants
> , or just pick some decent values and stick with them?
It's up to you. What exactly do you mean by configuration information?
> 4) Edouard is writing a separate parallel_sort, and our intention is that it
> can take a separate sorting algorithm (such as integer_sort etc) as an
> Are we better off submitting our source for final review separately or
> They're intended to be in the same library
It doesn't make a difference to me...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk