Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!rutgers!maverick.ksu.ksu.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!aglew From: aglew@dwarfs.crhc.uiuc.edu (Andy Glew) Newsgroups: comp.arch Subject: Re: 64 bits for times.... Message-ID: Date: 25 Aug 90 17:02:51 GMT References: <703@exodus.Eng.Sun.COM> <67633@sgi.sgi.com> <957@halley.UUCP> <1990Aug24.181208.29581@rice.edu> <41090@mips.mips.COM> Sender: usenet@ux1.cso.uiuc.edu (News) Organization: University of Illinois, Computer Systems Group Lines: 38 In-Reply-To: mash@mips.COM's message of 24 Aug 90 23:34:59 GMT >[Preston Briggs] >I'd guess that on modern machines, the Heisenburg Uncertainty >principle comes into play. You can't measure the time of a single >instruction usefully because the measurement code interferes >with the cache and various pipelines. >[John Mashey] >Not only does the measurement code change the context, but even if it >didn't, it's ALMOST USELESS to be trying to measure the speed of >individual instructions on current machines. Please note that the guys above said that it is useless (1) to try to measure the speed of an individual instruction, not (2) that it is useless to try to measure the speeds of instruction aggregates to reveal individual instruction effects. Or do you want to extend your statements to cover (2), John and Preston? If so, then I disagree. Experimental physics hasn't stopped since Heisenburg. We just know a bit more about what we can and cannot measure. I would never suggest timing individual instructions. You can, however, time sequences of instructions - basic blocks may be too small, but critical paths through a function may be large enough (functions like syscall() come to mind), and you can time precisely enough to show the effects of individual instructions on these aggregates. Just make sure the ramp up and ramp down effects can be accounted for or averaged out. Even then, measurement changes the context - but you account for that by minimizing the measurement distortion, and designing your measurement code so that the distortion is unidirectional - so that you get an upper or lower bound from your measurement. If what you are trying to do is, eg. set a strict upper bound on context switch time (hello hard RT - and, yes, I know about the probabilistic effects of caches) a bound is all you need. -- Andy Glew, a-glew@uiuc.edu [get ph nameserver from uxc.cso.uiuc.edu:net/qi]