Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!amdahl!littauer From: littauer@amdahl.amdahl.com (Tom Littauer) Newsgroups: comp.arch Subject: Re: Sort Co-Processors Message-ID: <15890@amdahl.amdahl.com> Date: Fri, 9-Oct-87 14:39:37 EDT Article-I.D.: amdahl.15890 Posted: Fri Oct 9 14:39:37 1987 Date-Received: Sun, 11-Oct-87 14:38:14 EDT References: <112@sdeggo.UUCP> <2967@husc6.UUCP> Reply-To: littauer@amdahl.amdahl.com (Tom Littauer) Organization: Amdahl Corp, Sunnyvale CA Lines: 32 Summary: IBM Sort Assist Feature In article <2967@husc6.UUCP> reiter@harvard.UUCP (Ehud Reiter) writes: >In article <112@sdeggo.UUCP> dave@sdeggo.UUCP (David L. Smith) writes: >>Has anyone out there ever run across a sorting co-processor? ... >However, the main problem with a sort co-processor is that sorting tends to >be an I/O intensive task. ... > In fact, I believe that >traditionally, database people have completely ignored CPU time and looked only >at I/O time when computing the expected times for sorts, joins, etc. >So, sorting coprocessors are possible, but the problem goes far beyond >designing clever VLSI comparison circuits, which is what most people seem >to do. *** Bias warning and disclaimer *** I've been disliking IBM for 22 years now, and I work for a company that competes with them (and nicely, too :-). The following opinions are mine, not (necessarily) Amdahl's. *** we now return to our program *** This didn't prevent IBM from ballyhooing (that IS a proper word, isn't it :-) the Sort Assist Feature on some of their CPUs. Net result: their sort (assisted) still didn't beat SyncSort (unassisted). More smoke and mirrors intended to confuse CPU buyers. -- UUCP: littauer@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,ihnp4,ames,uunet,cbosgd}!amdahl!littauer DDD: (408) 737-5056 USPS: Amdahl Corp. M/S 330, 1250 E. Arques Av, Sunnyvale, CA 94086 I'll tell you when I'm giving you the party line. The rest of the time it's my very own ravings (accept no substitutes).