
Parallel In-Place Merge Sort - r4um
http://www.drdobbs.com/parallel/parallel-in-place-merge-sort/240169094
======
wfunction
It's really silly that they depend on the STL implementations, because I don't
believe STL implementations actually implement in-place merges in-place. The
actual problem of stable in-place merge is extremely hard, so I was really
surprised it would show up in a Dr. Dobbs article.

~~~
aidanhs
A stable in-place merge sort is actually reasonably easy to implement if you
happen to be using a linked list -
[http://www.chiark.greenend.org.uk/~sgtatham/algorithms/lists...](http://www.chiark.greenend.org.uk/~sgtatham/algorithms/listsort.html)

I think it's interesting how choice of data structure affects algorithm
characteristics.

~~~
StefanKarpinski
Using a linked list is effectively equivalent to doing things not in place.
Except that the memory locality is worse and for word-sized data like integers
and floats, the overhead is permanent 3x instead of just temporary 2x. But
yes, for linked lists, merge sort is a great choice since it doesn't depend on
O(1) indexing.

~~~
wfunction
Yeah, exactly. For those who didn't catch it: linked lists already have O(log
n) overhead, because distinguishing between n items requires log n bits for
the pointer. They're fundamentally not in-place.

~~~
aidanhs
Hmm, I was thinking 'in-place' in the context of 'no extra memory needed'. Is
this not correct?

For sure, if it doesn't make sense to use a linked list in the first place
then linked list merge sort definitely doesn't make sense...

~~~
wfunction
It's not that it's incorrect, it's that it's pointless. The entire point of a
linked list is that you don't move around the data, you just re-link nodes. So
any sane algorithm that works on linked lists is already "in-place" by
default; an out-of-place merge on a linked list would be pure madness. So
saying that an in-place merge can be performed on a data structure that
already has some overhead and which _already_ performs everything in place is
not a very insightful or useful observation.

~~~
aidanhs
> an out-of-place merge on a linked list would be pure madness

Absolutely. I'm not even sure how you would do such a thing.

I personally have found it interesting when considering the difference between
an array of pointers and a linked list, simply because they both have the same
overhead but one doesn't require allocating any more memory for a merge sort.

I basically agree with what you say (maybe bar it not being useful knowledge)
but I don't think it's worth continuing trying to clarify my initial
statement.

------
taeric
Anyone have any quick comparisons of this to Batcher's sorting method? Quickly
consulting wikipedia, I see that those have gained traction in the GPGU
community. I was curious if/when those techniques would start to get use.

------
brudgers
While the approximately 10x increase of the parallel in-place merge sort over
the non-parallel version shown on the benchmarks may be meaningful, it also
shows that parallelism reduces constant factors, not exponents.

~~~
readerrrr
It is impossible to get anything better than a constant improvement, if you
divide you work by a constant factor.

~~~
brudgers
Not discussing that is a weakness of the article. The algorithm addresses
performance issues caused by the IO bottleneck, not an algorithmic deficiency
with common merge-sort implementations.

The merits and deficits of trading-off O(n)[Memory] growth for 0(log
n)^2[Time] growth are worthy of discussion if it is anticipated that people
will implement the algorithm in production code. There's a case for looking at
it, certainly, on constrained systems, but such systems may not have
processors with the execution pipeline sophistication of an Intel i7 quad-
core.

Which of course is just a round about way of saying, the article doesn't
indicate domains in which the algorithm may be relevant and not relevant.

------
govilk
similar to java8 feature, fork and join

