home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / arch / 8316 < prev    next >
Encoding:
Internet Message Format  |  1992-07-25  |  1.6 KB

  1. Path: sparky!uunet!olivea!decwrl!sgi!rhyolite!vjs
  2. From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
  3. Newsgroups: comp.arch
  4. Subject: Re: bcopy (was Re: CISC Microcode)
  5. Message-ID: <nod3g5c@rhyolite.wpd.sgi.com>
  6. Date: 25 Jul 92 18:50:06 GMT
  7. References: <1992Jul15.054020.1@eagle.wesleyan.edu> <l71bboINN4en@exodus.Eng.Sun.COM>
  8. Organization: Silicon Graphics, Inc.  Mountain View, CA
  9. Lines: 33
  10.  
  11. In article <l71bboINN4en@exodus.Eng.Sun.COM>, narad@nonsequitur.Eng.Sun.COM (Chuck Narad) writes:
  12. > ...
  13. > This can also be used to bfill/bzero pages efficiently.  This allows us
  14. > to accelerate relatively- aligned copies in kernel space, which covers
  15. > many of the interesting cases including page copy, copy-on-write,
  16. > networking buffers, etc....
  17.  
  18.  
  19. > ....The answer is that sometimes you want the data now, and sometimes 
  20. >you don't.  For example, moving data through several layers of network protocol
  21. > stacks,...
  22.  
  23.  
  24. Ha!  Finally I get not one but two openings for my $0.02.
  25.  
  26. The Right way to fix network bcopy()'s is to not do them.
  27. In a wrong system, bcopy() and the consequent cache hassles dominated.
  28. In a right system, TCP or UDP user data goes from the wire to main RAM
  29. to disk or video or the reverse without ever seeing the CPU.
  30.  
  31. The common network benchmarks I know of do not examine the data on the
  32. receiving end nor change it on the transmitting end.  This means that a
  33. Right system can go a lot faster on those benchmarks.  yes, that is
  34. one reason why we get several dozen Mbit/sec out of FDDI than some
  35. other guys.
  36.  
  37.  
  38. Instead of getting a headache pill because hitting your head with a
  39. hammer hurts, "don't do that."
  40.  
  41.  
  42.  
  43. Vernon Schryver,  vjs@sgi.com
  44.