Parallelize main memory sort phase about java-merge-sort HOT 2 OPEN

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.

from java-merge-sort.

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)

from java-merge-sort.