home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / arch / 11865 < prev    next >
Encoding:
Internet Message Format  |  1992-12-22  |  1.4 KB
  1. Xref: sparky comp.arch:11865 comp.sys.intel:2812
  2. Path: sparky!uunet!ibmarc!rufus.almaden.ibm.com!shoens
  3. From: shoens@rufus.almaden.ibm.com
  4. Newsgroups: comp.arch,comp.sys.intel
  5. Subject: Re: Superscalar vs. multiple CPUs ?
  6. Message-ID: <2121@coyote.UUCP>
  7. Date: 22 Dec 92 17:41:13 GMT
  8. References: <1992Dec7.012026.11482@athena.mit.edu> <PCG.92Dec11162630@aberdb.aber.ac.uk> <1992Dec21.134531.3253@athena.mit.edu>
  9. Sender: news@ibmarc.UUCP
  10. Reply-To: shoens@almaden.ibm.com
  11. Organization: IBM Almaden Research Center
  12. Lines: 17
  13. Nntp-Posting-Host: rufus.almaden.ibm.com
  14.  
  15. Jason Solinsky  ...
  16.  
  17. > In how many of these examples are we actually concerned with processor
  18. > performance?  In editors and word processors we certainly aren't ...
  19. > In the case of a database, I would not expect it to be processor limited.
  20.  
  21. As you have more cycles to fool with you get to put more function in,
  22. of course.  So where I previously edited nroff source with ed, I now
  23. use a system like Framemaker with X-windows.  Database systems are
  24. typically CPU bound because disks have been slow forever, so the problem
  25. of disk parallelism has already been tackled.  Besides, if you analyze
  26. the popular transaction benchmarks you can see that the disk bandwidth
  27. required is relatively small, assuming reasonably-sized buffer pools.
  28. For complex queries, there's even more processing to do and more opportunity
  29. for smart data placement on disk and sequential prefetch.
  30. --
  31. Kurt Shoens
  32.