home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / arch / 8184 < prev    next >
Encoding:
Text File  |  1992-07-21  |  1.6 KB  |  32 lines
  1. Newsgroups: comp.arch
  2. Path: sparky!uunet!sun-barr!cs.utexas.edu!torn!utzoo!henry
  3. From: henry@zoo.toronto.edu (Henry Spencer)
  4. Subject: Re: MVC and MVCL (was Re: RISC Mainframe)
  5. Message-ID: <BrrBvA.E0w@zoo.toronto.edu>
  6. Date: Tue, 21 Jul 1992 21:04:21 GMT
  7. References: <1992Jul14.181115.1@eagle.wesleyan.edu> <e83w02h719R301@JUTS.ccc.amdahl.com> <BrM7Mw.DIp@zoo.toronto.edu> <1992Jul19.212901.8857@bcars64a.bnr.ca>
  8. Organization: U of Toronto Zoology
  9. Lines: 21
  10.  
  11. In article <1992Jul19.212901.8857@bcars64a.bnr.ca> schow@bqneh3.bnr.ca (Stanley T.H. Chow) writes:
  12. >>Of course, a RISC bigot like me :-) would say that this means your machine
  13. >>is unbalanced:  the hardware has useful capabilities that the software is
  14. >>unable to exploit in a general-purpose way.  A straight byte-for-byte copy
  15. >>is not the only thing one might want to do at top speed...
  16. >
  17. >Ah, I see you belong to the rewrite-code-for-each-new-machine school
  18. >of programming. Otherwise, how do you write optimal loops that depend
  19. >on the cache line transfer size?
  20.  
  21. One obvious possibility is to generate them automatically, perhaps even
  22. on the fly, perhaps just in a shared library.
  23.  
  24. The fact is, rewriting the code -- in some way, not necessarily involving
  25. human effort or maintaining multiple versions -- *makes it run faster*.
  26. If it's worth the trouble, you find a way to do it.  If it's worthwhile
  27. for bcopy, it's probably worthwhile for (some) other things for at least
  28. some customers... if the machine will let you.
  29. -- 
  30. There is nothing wrong with making      | Henry Spencer @ U of Toronto Zoology
  31. mistakes, but... make *new* ones. -D.Sim|  henry@zoo.toronto.edu  utzoo!henry
  32.