Parallel String Sample Sort

Bingmann, Timo; Sanders, Peter

doi:10.1007/978-3-642-40450-4_15

Cited by 18 publications

(37 citation statements)

References 14 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The radix sort implementation by Rantala performs the best for most of the data sets when compared with the other state‐of‐the‐art string sorting algorithms. For the artificial data set, burst sort outperforms both the serial MKQS and the radix sort implemented by Rantala by a margin of 4.99% and 13.17%. MKQS performs very poorly in its serial version, the main reason being its inherent recursive nature.…”

Section: Experimental Results and Performance Analysismentioning

confidence: 99%

Kepler GPU accelerated recursive sorting using dynamic parallelism

Neelima¹,

Shamsundar²,

Narayan

et al. 2016

Concurrency and Computation

View full text Add to dashboard Cite

Summary This paper focuses on the performance gain obtained on the Kepler graphics processing units (GPUs) for multi‐key quicksort. Because multi‐key quicksort is a recursive‐based algorithm, many of the researchers have found it tedious to parallelize the algorithm on the multi and many core architectures. A survey of the state‐of‐the‐art string sorting algorithms and a robust insight of the Kepler GPU architecture gave rise to an intriguing research idea of matching the template of multi‐key quicksort with the dynamic parallelism feature offered by the Kepler‐based GPU's. The CPU parallel implementation has an improvement of 33 to 50% and 62 to 75 improvement when compared with 8‐bit and 16‐bit parallel most significant digit radix sort, respectively. The GPU implementation of multi‐key quicksort gives 6× to 18× speed up compared with the CPU parallel implementation of parallel multi‐key quicksort. The GPU implementation of multi‐key quicksort achieves 1.5× to 3× speed up when compared with the GPU implementation of string sorting algorithm using singleton elements in the literature. Copyright © 2016 John Wiley & Sons, Ltd.

show abstract

Section: Experimental Results and Performance Analysismentioning

confidence: 99%

Kepler GPU accelerated recursive sorting using dynamic parallelism

Neelima¹,

Shamsundar²,

Narayan

et al. 2016

Concurrency and Computation

View full text Add to dashboard Cite

show abstract

“…Thus, in terms of core performance-per-power, little cores are the best with around 800 MIPS/W, big cores come second with 180 MIPS/W and Xeon cores are the worst with 40 MIPS/W. To measure memory bandwidth we use pmbw 0.6.2 (Parallel Memory Bandwidth Benchmark) [7]. Figure 1 plots the memory bandwidth of Xeon and the three ARM configurations, in log-log scale.…”

Section: Benchmark Resultsmentioning

confidence: 99%

A performance study of big data on small nodes

et al. 2015

View full text Add to dashboard Cite

The continuous increase in volume, variety and velocity of Big Data exposes datacenter resource scaling to an energy utilization problem. Traditionally, datacenters employ x86-64 (big) server nodes with power usage of tens to hundreds of Watts. But lately, low-power (small) systems originally developed for mobile devices have seen significant improvements in performance. These improvements could lead to the adoption of such small systems in servers, as announced by major industry players. In this context, we systematically conduct a performance study of Big Data execution on small nodes in comparison with traditional big nodes, and present insights that would be useful for future development. We run Hadoop MapReduce, MySQL and in-memory Shark workloads on clusters of ARM big.LITTLE boards and Intel Xeon server systems. We evaluate execution time, energy usage and total cost of running the workloads on selfhosted ARM and Xeon nodes. Our study shows that there is no one size fits all rule for judging the efficiency of executing Big Data workloads on small and big nodes. But small memory size, low memory and I/O bandwidths, and software immaturity concur in canceling the lower-power advantage of ARM servers. We show that I/O-intensive MapReduce workloads are more energy-efficient to run on Xeon nodes. In contrast, database query processing is always more energy-efficient on ARM servers, at the cost of slightly lower throughput. With minor software modifications, CPU-intensive MapReduce workloads are almost four times cheaper to execute on ARM servers.

show abstract

“…Quicksort 20 can be seen as a specialization of sample sort with fixed parameter k = 2. Sample sort is very popular for sorting large amounts of items on distributed systems, 30‐32 on GPUs, 33 and also for strings 34,35 …”

Section: Register Sample Sortmentioning

confidence: 99%

Engineering faster sorters for small sets of items

2020

Self Cite

View full text Add to dashboard Cite

Sorting a set of items is a task that can be useful by itself or as a building block for more complex operations. That is why a lot of effort has been put into finding sorting algorithms that sort large sets as efficiently as possible. But the more sophisticated and complex the algorithms become, the less efficient they are for small sets of items due to large constant factors. A relatively simple sorting algorithm that is often used as a base case sorter is insertion sort, because it has small code size and small constant factors influencing its execution time. We aim to determine if there is a faster way to sort small sets of items to provide an efficient base case sorter. We looked at sorting networks, at how they can improve the speed of sorting few elements, and how to implement them in an efficient manner using conditional moves. Since sorting networks need to be implemented explicitly for each set size, providing networks for larger sizes becomes less efficient due to increased code sizes. To also enable the sorting of slightly larger base cases, we adapted sample sort to Register Sample Sort, to break down those larger sets into sizes that can in turn be sorted by sorting networks. From our experiments we found that when sorting only small sets of integers, the sorting networks outperform insertion sort by a factor of at least 1.76 for any array size between six and 16, and by a factor of 2.72 on average across all machines and array sizes. When integrating sorting networks as a base case sorter into Quicksort, we achieved far less performance improvements over using insertion sort, which is probably due to the networks having a larger code size and cluttering the L1 instruction cache. The same effect occurs when including Register Sample Sort as a base case sorter for IPS4o. But for x86 machines that have a larger L1 instruction cache of 64 KiB or more, we obtained speedups of 12.7% when using sorting networks as a base case sorter in std::sort, and of 5%–6% when integrating Register Sample Sort as a base case sorter into IPS4o, each in comparison to using insertion sort as the base case sorter. In conclusion, the desired improvement in speed could only be achieved under special circumstances, but the results clearly show the potential of using conditional moves in the field of sorting algorithms.

show abstract

Parallel String Sample Sort

Cited by 18 publications

References 14 publications

Kepler GPU accelerated recursive sorting using dynamic parallelism

Kepler GPU accelerated recursive sorting using dynamic parallelism

A performance study of big data on small nodes

Engineering faster sorters for small sets of items

Contact Info

Product

Resources

About