On Jan 22, 4:24 pm, e <evier...@gmail.com> wrote: > At first, there will only be one thread for the first pass, but the number > will grow as subtasks fire sub-sub tasks. I am sure this is a silly way to > sort because the threadspawning time is so much longer than the filtering > time, but it's just an exercise.
It's also not so efficient because in Quicksort, the pivot isn't always in the middle of the current subarray. That means different agents will probably get different array sizes and thus you will lose performance through load imbalance. Parallel Quicksort can only be made efficient if the language supports efficient nested parallelism. mfh --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---