Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site sbcs.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!mtuxo!mtunh!mtung!mtunf!ariel!vax135!timeinc!phri!pesnta!amd!amdcad!amdimage!prls!philabs!sbcs!debray From: debray@sbcs.UUCP (Saumya Debray) Newsgroups: net.math Subject: Re: Constant time sort? Message-ID: <342@sbcs.UUCP> Date: Sat, 29-Jun-85 14:24:57 EDT Article-I.D.: sbcs.342 Posted: Sat Jun 29 14:24:57 1985 Date-Received: Wed, 3-Jul-85 08:31:52 EDT References: <77@rtp47.UUCP> Organization: Computer Science Dept, SUNY@Stony Brook Lines: 24 Wayne Throop: > A recent posting refered to a "constant time sort using n processors". > Given comparison sorting, even using n processors to sort n items, it > seems that it would require O(logN) time, not constant time. Am I > right, or am I forgetting something? > You're right. In fact, most parallel sort algorithms that have been suggested (e.g. by Batcher, by Thompson & Kung) on common configurations like broadcast-bus networks, the butterfly, the shuffle-exchange network, grid networks etc., take O( log^2(N) ) time. A recent paper by Ullman cites an algorithm by Ajtai that takes O(log N) time on a broadcast-bus network, (though with very high overhead!). I should point out that these algorithms assume a fixed order of the nodes, p1 ... pN, independent of the elements at the nodes, and take "sort" to mean that the largest element has to be brought to p1, the next largest to p2, and so on. -- Saumya Debray SUNY at Stony Brook uucp: {allegra, hocsd, philabs, ogcvax} !sbcs!debray arpa: debray%suny-sb.csnet@csnet-relay.arpa CSNet: debray@sbcs.csnet