Re: [boost] Proposed templated integer_sort

Subject: Re: [boost] Proposed templated integer_sort
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2009-01-14 12:55:36

AMDG

Steven Ross wrote:
> 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.
>   

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
> 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.
>   

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
> 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?
>   

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
> 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.
>   

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

It doesn't make a difference to me...

In Christ,
Steven Watanabe