Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Parallelize main memory sort phase #2

Open
whoschek opened this issue Dec 11, 2011 · 2 comments
Open

Parallelize main memory sort phase #2

whoschek opened this issue Dec 11, 2011 · 2 comments

Comments

@whoschek
Copy link

Suggestion: It might be worthwhile to parallelize the main memory sort phase for better performance. For example, using jsr166y an array can be sorted in parallel simply like this: ParallelArray.createUsingHandoff(Object[], ForkJoinPool).sort(Comparator).getArray()

Note, however, that with that algorithm implementation the sort might not be "stable" anymore, i.e. the relative order of equal elements might change.

@cowtowncoder
Copy link
Owner

I think it's good idea to make pre-sort more pluggable -- at one point it was bit more prominently separate, but I simplified things. Might be good idea to go back, have a look, give user a choice. Especially given prominence of multi-CPU boxes.

After this, could perhaps consider parallelization of merge step too, although quite commonly it will be i/o bound I assume? But with SSDs, more complex handling (data-binding for in/out), not necessarily.

@whoschek
Copy link
Author

The comparison function may be expensive and so reducing the number of comparisons (e.g. with a log n PriorityQueue) is important.

Also, I think because external merge sort works with (parallel) sequential streams, I/O isn't necessarily the bottleneck even without SSDs. Rotational disks have good bandwidth on sequential I/O. With a standard 4+4 hardware RAID 10 disk array of rotational 10k RPM disk drives we see 500 MB/s seq reads and 500 MB/s seq writes, all for 100 parallel sequential streams.

(To get good perf with that many parallel streams we had to tune linux ext4 to do 16 MB block device read ahead via
/sbin/blockdev --setra 32768 /dev/mapper/vgskytide2-lvskytide2)

Wolfgang.

On Dec 11, 2011, at 9:56 AM, Tatu Saloranta wrote:

I think it's good idea to make pre-sort more pluggable -- at one point it was bit more prominently separate, but I simplified things. Might be good idea to go back, have a look, give user a choice. Especially given prominence of multi-CPU boxes.

After this, could perhaps consider parallelization of merge step too, although quite commonly it will be i/o bound I assume? But with SSDs, more complex handling (data-binding for in/out), not necessarily.


Reply to this email directly or view it on GitHub:
#2 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants