home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / sys / intel / 2747 < prev    next >
Encoding:
Internet Message Format  |  1992-12-17  |  2.1 KB
  1. Xref: sparky comp.sys.intel:2747 comp.arch:11728
  2. Path: sparky!uunet!stanford.edu!rock!concert!duke!psu
  3. From: psu@cs.duke.edu (Peter Su)
  4. Newsgroups: comp.sys.intel,comp.arch
  5. Subject: Re: Superscalar vs. multiple CPUs ?
  6. Message-ID: <PSU.92Dec17094221@ptero.cs.duke.edu>
  7. Date: 17 Dec 92 14:42:21 GMT
  8. References: <WAYNE.92Dec4093422@backbone.uucp> <37595@cbmvax.commodore.com>
  9.     <PCG.92Dec9154602@aberdb.aber.ac.uk>
  10.     <1992Dec10.002951.23336@athena.mit.edu>
  11.     <PCG.92Dec13170504@aberdb.aber.ac.uk>
  12. Sender: news@duke.cs.duke.edu
  13. Followup-To: comp.sys.intel
  14. Organization: Duke University CS Dept., Durham, NC
  15. Lines: 35
  16. Nntp-Posting-Host: ptero.cs.duke.edu
  17. In-reply-to: pcg@aber.ac.uk's message of 13 Dec 92 17:05:04 GMT
  18.  
  19. In article <PCG.92Dec13170504@aberdb.aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes:
  20.    Precisely my point: single threaded *general purpose* codes have a
  21.    limited intrinsic degree of exploitable parallelism .
  22.  
  23.     ...
  24.  
  25.    So far the evidence seems (to me at least) that exploitable degrees of
  26.    micro (multiple instruction issue in a cycle) and macro (multiple
  27.    instruction streams in a program) parallelism for most codes don't go
  28.    above 2-4; only codes with highly regular data reference patterns can be
  29.    micro/macro parallelized with success/ease.
  30.  
  31. This sort of begs the question: if current code can't use these
  32. architectures well because it wasn't designed to be parallel, why not
  33. start the slow move towards code that *was* designed with these
  34. architectures in mind?
  35.  
  36. It is possible to make irregular code (say, unstructured sparse matrix
  37. ops) perform well, even on vector machines.  It is unlikely that a
  38. compiler will do it for you.
  39.  
  40. It seems to me that the industry spends a huge amount of time trying
  41. to mash old code until it runs fast when it could instead try to
  42. figure out better algorithms and make sure that the systems needed to
  43. get that software up fast and perform well is available.
  44.  
  45. Everyone who moves to a  new class of architectures has to expect to
  46. rewrite their code, don't they?
  47.  
  48. Flame suit on,
  49. Pete
  50. --
  51. Department of Computer Science, Duke University, Durham, NC 27706
  52. Internet:    psu@cs.duke.edu
  53. UUCP:        mcnc!duke!psu
  54.