Wed Sep 7 01:28:02 CEST 2005
bokr at oz.net (Bengt Richter) writes:
> >And I'm fairly certain that 'sort' won't start spending CPU time
> >until it has collected all its input, so you won't gain much
> >there either.
> Why wouldn't a large sequence sort be internally broken down into parallel
> sub-sequence sorts and merges that separate processors can work on?
Usually the input would be split into runs that would get sorted in
memory. Conventional wisdom says that the most important factor in
speeding up those sorts is making the runs as long as possible.
Depending on how complicated comparing two elements is, it's not clear
whether increased cache pressure from parallel processors hitting
different regions of memory would slow down the sort more than
parallelism would speed it up. Certainly any sorting utility that
tried to use parallel processors should use algorithms carefully
chosen and tuned around such issues.
More information about the Python-list