home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / arch / 11883 < prev    next >
Encoding:
Internet Message Format  |  1992-12-22  |  2.7 KB
  1. Xref: sparky comp.arch:11883 comp.sys.intel:2815
  2. Newsgroups: comp.arch,comp.sys.intel
  3. Path: sparky!uunet!gatech!rpi!think.com!enterpoop.mit.edu!bloom-picayune.mit.edu!athena.mit.edu!solman
  4. From: solman@athena.mit.edu (Jason W Solinsky)
  5. Subject: Re: Superscalar vs. multiple CPUs ?
  6. Message-ID: <1992Dec23.025403.21926@athena.mit.edu>
  7. Sender: news@athena.mit.edu (News system)
  8. Nntp-Posting-Host: m37-318-11.mit.edu
  9. Organization: Massachusetts Institute of Technology
  10. References: <1992Dec7.012026.11482@athena.mit.edu> <PCG.92Dec11162630@aberdb.aber.ac.uk> <1992Dec21.134531.3253@athena.mit.edu> <2121@coyote.UUCP>
  11. Date: Wed, 23 Dec 1992 02:54:03 GMT
  12. Lines: 37
  13.  
  14. In article <2121@coyote.UUCP>, shoens@rufus.almaden.ibm.com writes:
  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. Several people wrote me concerning the fact that their word processors and
  32. editors do this, that, and the other thing. HOWEVER, in all of those cases and
  33. apparently in the two examples mentioned above, there exists a huge (or at the
  34. very least presently underutilized) degree of parallelism. When you have an
  35. idle CPU there will always be additional things that software people would
  36. like to run on it, but the practical examples are OVERWHELMINGLY
  37. under-parallelized in their present day incarnations.
  38.  
  39. This is certainly true of a CPU running an editor while updating several macros
  40. within the editor and then running several tasks in the background. It is again
  41. true of most database programs which will typically be very parallelizable
  42. at the higher levels of examination.
  43.  
  44. What I am trying to say is that when a task which has been non-cpu bound, is
  45. modified such that it becomes cpu-bound, the modifications invloved are
  46. typically excellent candidates for parallelization. Thus it still holds that
  47. "general purpose" computing can support the degree of parallelization available
  48. to a deep pipelined "hyperscalar" uP.
  49.  
  50. Jason W. Solinsky
  51.