Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!stanford.edu!neon.Stanford.EDU!torrie From: torrie@cs.stanford.edu (Evan Torrie) Newsgroups: comp.sys.amiga.advocacy Subject: Re: Peter, can you explain to the Amigoids (was: NeXT software size Message-ID: <1991May8.013155.14300@neon.Stanford.EDU> Date: 8 May 91 01:31:55 GMT References: <11905@uwm.edu> Sender: torrie@neon.Stanford.EDU (Evan James Torrie) Organization: Computer Science Department, Stanford University, Ca , USA Lines: 46 gblock@csd4.csd.uwm.edu (Gregory R Block) writes: >From article , by sutela@polaris.utu.fi (Kari Sutela): >> gblock@csd4.csd.uwm.edu (Gregory R Block) writes: >> >> >> Let's take an example. There are two cars: a red one and a blue one. >> Both are driving at 60mph. The red car is driving on a 1 mile track >> while the blue car is on a 2 mile track. Obviously, the red car finishes >> in one minute, while it takes two minutes for the blue car to complete >> the track. So, you are seriously saying that the blue car is slower? >> >> You are confuzed. Pick a better argument. >> >I am confused by that. Okay, I'll try again. >If a program (a track?) is 1/2 mile (512k) long, and another program >is 2 miles (2048k) long, and both cars (processors), both v-8 (68040), >are running at 120mph (25mhz) down the track, the one on the 1/2 mile >track will finish first... Of course, I've completely forgotten the >point I was trying to make, but I'm sure this proved it. :) Both of these analogies are wrong, since they assume that the execution time of the program is directly proportional to its size. This would be true if this were straight-line code, but programs tend to have these funny things called "loops" and "branches" in them. Execution time depends on the frequency with which these loops and branches are executed. You cannot consider execution time based on a static analysis of the code, you need to also consider the dynamic frequencies. It's quite possible (and indeed likely) that the 2MB of code actually has a core inner loop of only 10-20K, which gets executed 90-95% of the time. The other MB of code would be infrequently travelled, possibly only for obscure features. Summary: You can't make a prediction of dynamic execution time by looking at a static attribute like program size. -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu "And in the death, as the last few corpses lay rotting in the slimy thoroughfare, the shutters lifted in inches, high on Poacher's Hill..."