Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!mips!winchester!mash
From: mash@mips.COM (John Mashey)
Newsgroups: comp.arch
Subject: Re: 64 bits for times....
Message-ID: <41096@mips.mips.COM>
Date: 25 Aug 90 19:51:45 GMT
References: <703@exodus.Eng.Sun.COM> <67633@sgi.sgi.com> <957@halley.UUCP> <1990Aug24.181208.29581@rice.edu> <41090@mips.mips.COM> <AGLEW.90Aug25130251@dwarfs.crhc.uiuc.edu>
Sender: news@mips.COM
Reply-To: mash@mips.COM (John Mashey)
Organization: MIPS Computer Systems, Inc.
Lines: 41

In article <AGLEW.90Aug25130251@dwarfs.crhc.uiuc.edu> aglew@dwarfs.crhc.uiuc.edu (Andy Glew) writes:
>>[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.

No, of course not.  It is perfectly reasonable to measure aggregates,
subject to all of the caveats that have been mentioned in this
discussion so far.  The bigger & more realistic the aggregates, the
better.  In addition, it will get worse.
Hopefully, people now understand the uselessness of single-instruction
measurements on current machines.  If you agree to this, for the
kinds of pipelines that most current machines use, consider how much
worse it gets with:
	vector units
	superscalar
	superpipelined
	superscalar-superpipelined
	out-of-order execution
	speculative execution
	multi-level cache hierarchies, with various inter-level buffering
since all of these are either here already, or possibly coming soon,
in microprocessors.
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	 mash@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash 
DDD:  	408-524-7015, 524-8253 or (main number) 408-720-1700
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086