home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / arch / 8343 < prev    next >
Encoding:
Text File  |  1992-07-26  |  3.0 KB  |  78 lines
  1. Newsgroups: comp.arch
  2. Path: sparky!uunet!iWarp.intel.com|ichips!ichips!glew
  3. From: glew@pdx007.intel.com (Andy Glew)
  4. Subject: Re: Request Info Re Bus Trends & Intel 486s
  5. In-Reply-To: pettengill@cvg.enet.dec.com's message of Sat, 25 Jul 92 05:31:24 GMT
  6. Message-ID: <GLEW.92Jul26200841@pdx007.intel.com>
  7. Sender: news@ichips.intel.com (News Account)
  8. Organization: Intel Corp., Hillsboro, Oregon
  9. References: <rjmartin.711191773@extro.ucc.su.OZ.AU> <1992Jul20.003506.23290@theus.rain.com>
  10.     <GLEW.92Jul23192755@pdx007.intel.com>
  11.     <1992Jul25.053124.14505@e2big.mko.dec.com>
  12. Date: Mon, 27 Jul 1992 04:08:41 GMT
  13. Lines: 63
  14.  
  15.     |>[Burkhard Neidecker-Lutz]
  16.     |>Can you explain which *desktop* applications need peer-to-peer communication ?
  17.     |>I.e. what is wrong with going through main memory ?
  18.     |>>
  19.     |>>[John Theus]
  20.     |>>To use today's favorite buzz word: multimedia.
  21.     |>>
  22.     |>[Andy Glew]
  23.     |>First you'll put video on your screen.
  24.     |>
  25.     |>Then you'll want special effects: things like zooming in on a
  26.     |>particular speaker (or the papers on his desk) in a video conference,
  27.     |>things like cropping speakers from different video inputs and
  28.     |>superimposing them into a virtual conference room.
  29.  
  30.     I assume from the tone of his note that Andy is arguing for peer to peer...
  31.  
  32. Not really.
  33.  
  34. Peer to peer has a performance advantage (if it can be achieved).
  35.  
  36. But if you want to do more processing than either of your peers can
  37. handle, you'll want to go to the CPU.
  38.  
  39. So I'll take my typical waffling stance:
  40.  
  41. (1) I will never base a computer system architecture [*] on the assumption
  42.     that peer-to-peer communication for things like video is the only
  43.     important thing.
  44.  
  45. (2) I will try to optimize communication involving the CPU as much as
  46.     possible.
  47.  
  48. (3) I will also try not to *prevent* peer-to-peer communication from
  49.     being used.
  50.  
  51. [*] Not if the architecture is intended to stay up for several years.
  52.     If it is a purely one-shot deal, I guess that the thing to do
  53.     is to look at the technology wheel and try for the optimal solution
  54.     projected for your delivery date.  But the wheel turns at a rate
  55.     that approaches 1 turn/2 years (with major cycles of 1/8),
  56.     so if your design is going to be on the market that long plan for both.
  57.  
  58. It is wise to avoid self-fulfilling prophecies.  E.g. if you cripple
  59. your CPU by not providing the mechanisms to do fast bcopy, because you
  60. are assuming that extrernal hardware can always do it better, you have
  61. stuck yourself in a hole that it will be difficult to get out of when
  62. the technology wheel turns.  Conversely, if you don't put the features
  63. to do good peer-to-peer without CPU intervention in your bus, then you
  64. won't be able to get the performance boost it provides.
  65.  
  66. Best of both worlds?: TANSTAAFL. Emphasize the aspects that will be
  67. most important during your critical market window.  
  68. --
  69.  
  70. Andy Glew, glew@ichips.intel.com
  71. Intel Corp., M/S JF1-19, 5200 NE Elam Young Pkwy, 
  72. Hillsboro, Oregon 97124-6497
  73.  
  74. This is a private posting; it does not indicate opinions or positions
  75. of Intel Corp.
  76.  
  77. Intel Inside (tm)
  78.