Re^12: Can you improve upon my algorithm.

I used my own Sort::Packed for that.

I'm splitting the mapped file into buffers such that I can perform the sub-partitions sorts on 4 threads in parallel; which divides that part of the time by 4 - increase cache misses. (I haven't got a handle on that last part yet.)

I don't think there is any mileage in paral(lel)ising the N-way merge?

There are some possibilities for parallelising parts of the in-place merge (via insertion sort).

By using a smallish maximum heap as an "input buffer" to each of the partitions, records displaced from earlier partitions by insertions, can be rippled into place in reverse position order (in large part), which should reduce the number & depth of ripples involved.

So many possibilities. All I gotta do is wrap my brain around programming them :)

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". I'm with torvalds on this

In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked

Comment on Re^12: Can you improve upon my algorithm.