Re: [PATCH] sort: add --threads option to parallelize internal sort.

[Pádraig Brady]

I really like the patch.
Users get the benefit without needing to specify new options.
Also the overhead in the single threaded case is minimal.
Testing on my single core 1.7GHz pentium-m

seq -f%030.0f 1000000 | shuf > sort.in

$ time LANG=C src/sort.orig < sort.in > /dev/null
3.930s
$ time LANG=C src/sort.orig -S1M -T/dev/shm < sort.in > /dev/null
3.404s

$ time LANG=C src/sort < sort.in > /dev/null
3.838s (2.3% faster)
$ time LANG=C src/sort -S1M -T/dev/shm < sort.in > /dev/null
3.437s (1% slower)

The only thing I was questioning was the --threads option.
I've renamed that to --parallel in the attached patch
(along with other tweaks and cleanups). What do you think?

I still have a couple questions on the option though.
1. Is limiting the number to that returned by nproc()
always the right thing todo?
2. How does this option fit with the threaded external sort.
I.E. the integrated patches will need to share out the
threads to use, and perhaps multiple per CPU is appropriate,
especially in the presence of files on slow devices.

thanks a lot!
Pádraig.

sort-thread-mods.diff
Description: Text Data