Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!usc!sdd.hp.com!mips!winchester!mash From: mash@mips.COM (John Mashey) Newsgroups: comp.arch Subject: Re: 64 bits for times.... Message-ID: <41090@mips.mips.COM> Date: 24 Aug 90 23:34:59 GMT References: <703@exodus.Eng.Sun.COM> <67633@sgi.sgi.com> <957@halley.UUCP> <1990Aug24.181208.29581@rice.edu> Sender: news@mips.COM Reply-To: mash@mips.COM (John Mashey) Organization: MIPS Computer Systems, Inc. Lines: 35 In article <1990Aug24.181208.29581@rice.edu> preston@gefion.rice.edu (Preston Briggs) writes: ... >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. We can certainly measure how >long it takes to issue the instruction, but when does it complete? >In a particular context, it'll sometimes depend on the progress >of earlier instructions, etc. Inserting measurement code changes the >context. Preston is right on, and I'd say it even stronger: 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, and not just from cache and pipeline effects. Let's add (at least): conflicts with functional units (such as write ports into a register file) memory stalls (either from back-to-back stores, or load/store, or store/load) memory stalls (from running into DRAM refresh) memory stalls (write-buffers, or write-back caches) cache misses and maybe location of the instruction within the cache line Amongst the current machines, any one of these can have some effect, and there are plenty of others as pipelines get more complex. -- -john mashey DISCLAIMER: 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