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