Parallel In-Place Merge Sort

http://www.drdobbs.com/parallel/parallel-in-place-merge-sort/240169094

by r4um • 12 years ago

61 35 12 years ago

wfunction9• 12 years ago

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.

yelnatz• 12 years ago

Can you clarify what you mean by that?

Article said they got 2.2x improvement using their parallel method compared to STL. Trade off was having 100% CPU utilization vs 12.5% with STL.

rikkus• 12 years ago

That's not really a trade-off, if you're using the term with a negative connotation. Going from using 100% of one core to 100% of eight (well, 4, but hyperthreading) would normally be considered an advantage.

wfunction9• 12 years ago

Can you clarify what you mean by that?

I'm saying their merge sort was likely not actually in-place.

CJefferson3• 12 years ago

Certainly g++ does have an in-place merge sort. It's tricky in to activate it, because it is only used when an attempt to allocate a spare buffer fails, and on most 64-bit machines malloc doesn't fail, your program just gets killed later when it tries to use the memory.

wfunction9• 12 years ago

Are you talking about this?

https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-...

Do you know what the time complexity of their merging algorithm is?

As a side note, an optimal merging algorithm is in the paper called "On Optimal and Efficient in Place Merging", and it's too complicated for me to expect it in a standard library implementation. (Although the STL doesn't need to be optimal, I think the sub-optimal linear-time algorithms are also complicated enough to not be used for the standard library, but correct me if I'm wrong.)

aidanhs3• 12 years ago

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

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

wfunction9• 12 years ago

I don't think people have linked lists in mind when they talk about merge sort.

StefanKarpinski• 12 years ago

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.

taeric5• 12 years ago

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.

govilk• 12 years ago

similar to java8 feature, fork and join

brudgers5• 12 years ago

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• 12 years ago

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

brudgers5• 12 years ago

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.

sp332• 12 years ago

That's just what brudgers said. But don't worry, CPU and GPU manufacturers are increasing the number of cores exponentially :p

taeric5• 12 years ago

If you have a look at sorting networks, they actually do reduce an exponent. Goes from nlg(n) to just lg(n). See [1], for example.

Saying that, I feel like I'm trying to mislead, though. This requires nlg(n) comparators, so you still have to pay for it somehow. And I doubt we are going to see that many comparators on any piece of kit any time soon. For large n, anyway. (Though, seeing this can be done with a gpu, it does seem that you can hit rather large arrays already.)

[1] http://en.wikipedia.org/wiki/Batcher_odd%E2%80%93even_merges...

brudgers5• 12 years ago

[Assumption: n is large enough to make the problem interesting]

If a sorting network (such as Batcher's} requires O(n (log n)^2)[Space] doesn't this sort of defeat the purpose of trying to sort in-place?...since a traditional array copying merge-sort has 0(n)[Space] requirements.

Parallel In-Place Merge Sort

Related Stories