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