Re: [boost] Proposed templated integer_sort

Subject: Re: [boost] Proposed templated integer_sort
From: Steven Ross (spreadsort_at_[hidden])
Date: 2009-01-14 10:46:45

algorithm_sorting.tar.gz is now in the boost vault, and is formatted for
submission.
I'd appreciate it if people could test it on their compiler and give me some
feedback.
It's not quite ready for formal review yet; I'd like a test on MSVC++ first.

On Tue, Jan 13, 2009 at 9:02 AM, Steven Watanabe <watanabesj_at_[hidden]>wrote:

> 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
error:
/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.

Some questions:
1) I have a perl tuning/regression script that I've used to verify
correctness,
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
systems.
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
value
across all systems.
Should I include the tune.pl script with the library (and if so, where,
libs?),
or should I do all the performance tuning myself?

2) Should I have a separate constants.hpp to contain these constants (as
now),
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.

3) Should I use configuration information to set the constants
, or just pick some decent values and stick with them?

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
argument.
Are we better off submitting our source for final review separately or
together?
They're intended to be in the same library.