home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / sgi / 16104 < prev    next >
Encoding:
Internet Message Format  |  1992-11-08  |  1.4 KB
  1. Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!olivea!sgigate!odin!sgi!rhyolite!vjs
  2. From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
  3. Newsgroups: comp.sys.sgi
  4. Subject: Re: how to interrogate ftimer status from a program?
  5. Message-ID: <s1po0j4@rhyolite.wpd.sgi.com>
  6. Date: 7 Nov 92 00:02:08 GMT
  7. References: <23907@hacgate.SCG.HAC.COM> <1992Nov6.213506.12264@odin.corp.sgi.com>
  8. Organization: Silicon Graphics, Inc.  Mountain View, CA
  9. Lines: 22
  10.  
  11. In article <1992Nov6.213506.12264@odin.corp.sgi.com>, probins@bubba.wpd.sgi.com (Paul Robins) writes:
  12. > ...
  13. > Fast clock does not incur nearly the overhead of timers, but I don't have a
  14. > relative number. I've been assured that it is of neglible impact.
  15.  
  16.  
  17. A few years ago the number was either 5% or 15% of a CPU (I've
  18. forgotten which) to run the fast clock.  That is why it was not turned
  19. on by default.  More precisely, that is why ASD changed it from
  20. being on by default to being off by default.
  21.  
  22. Maybe that cost has changed.  Maybe some people now consider 5% (or 15?)
  23. "neglible."  Some did back then, until the issue was raised.
  24.  
  25. You can measure it for yourself.  Pick any CPU stupid benchmark
  26. (e.g. drhystone).  Run it with `ftimer -f off`, and then run it with
  27. `ftimer -f on`.  Do this several times to get consistent numbers.  As
  28. long as you change nothing else, the difference is the cost of fast
  29. timers.
  30.  
  31.  
  32. Vernon Schryver,   vjs@sgi.com
  33.