jbasara@ssdc (jim basara) (03/12/91)
Here's a novice question for you architecture folks. Could someone please provide me with a descriptive explaination of why MIP ratings are not a good way of comparing processing speed for RISC machines as opposed to MFLOPS? I would also like to know why companies are using MIP ratings for those machine s if they are not accurate. Is it possible that the MIP ratings can be manipulated so that a processor with a higher MIP rating may actually be considerably slower than one with a lower MIP rating??? What kinds of things do I need to be aware of when comparing processing speeds? thanks for your help jim basara uunet!ssdc!jbasara
sef@kithrup.COM (Sean Eric Fagan) (03/13/91)
In article <645@ssdc?> jbasara@ssdc (jim basara) writes: >Could someone please >provide me with a descriptive explaination of why MIP ratings are not a >good way of comparing processing speed for RISC machines as opposed to MFLOPS? MFLOPS aren't that great either, but there *is* a difference. Let's imagine a machine which can do an instruction fetch and decode in once cycle, and execute the instruction in another. Add one cycle for every "operation" it does (such as load from memory, store to memory, etc.). An instruction such as add $4, [0x100] ; encoded as 0x01040100 would take 4 cycles to fetch (assuming 8-bit bus, of course), one cycle to load from memory location 0x100, one cycle to add 4 to it, and one cycle to write the new value to location 0x100. A total of 7 cycles, no? If the machine ran at 10MHz, and we only consider that instruction, then we're talking about a slightly-larger-than-1 MIPS machinne, no? Now let's consider another instruction the processor has: NOP. NOP is encoded as 0xea. NOP takes one cycle to fetch and decode, and 0 cycles to run. A total of 1 cycle. Therefore, based on that instruction, the machine is a 10MIPS machine at 10MHz. Both measurements are, technically, correct. Now, as to why MFLOPS are different: because MFLOPS doesn't mean "Millions of FLoating-point instructions Per Second," it means "Millions of FLoating point Operations Per Second." A nop does (by definition) no operation on a floating-point value (although I've seen 'FNOP' instructions 8-)), so would not be counted. As a result, the measurements for MFLOPS tend to be a *little* more accurate than those for MIPS. All in all, though, go for SPECmarks. Much better. >I would also like to know why companies are using MIP ratings for those machine >s if they are not accurate. Sales. >Is it possible that the MIP ratings can be >manipulated so that a processor with a higher MIP rating may actually be >considerably slower than one with a lower MIP rating??? I think I answered that with my demonstration above. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
mmshah@athena.mit.edu (Milan M Shah) (03/14/91)
In article <645@ssdc?> jbasara@ssdc (jim basara) writes: >Here's a novice question for you architecture folks. Could someone please >provide me with a descriptive explaination of why MIP ratings are not a >good way of comparing processing speed for RISC machines as opposed to MFLOPS? >s if they are not accurate. Is it possible that the MIP ratings can be >manipulated so that a processor with a higher MIP rating may actually be >considerably slower than one with a lower MIP rating??? What kinds of things >do I need to be aware of when comparing processing speeds? > To quote from Patterson and Hennessy's _A Quatitative Approach_, pg 40-42, o MIPS can vary inversely with performance! The classic example (of the above point) is the MIPS rating of a machine with optional floating point hardware. Since it generally takes more clock cycles per floating-point instruction than per integer instruction, floating point programs using the optional hardware instead of software floating point routines take less time but have a *lower* MIPS rating. Software floating point executes simpler instructions, resulting in higher MIPS rating, but it executes so many more that overall execution time is longer. end-of-quote. Milan .
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (03/14/91)
In article <645@ssdc?> jbasara@ssdc (jim basara) writes: > Could someone please > provide me with a descriptive explaination of why MIP ratings are not a > good way of comparing processing speed for RISC machines as opposed to MFLOPS? I've got this Turing machine that runs at 5000 MIPS. That's right, it can move the tape back and forth 5 *billion* times a second. Impressed? You shouldn't be: it takes so many instructions to get something done on a Turing machine that the MIPS measurement is pointless. In contrast, MFLOPS measure some (supposedly) real amount of work getting done. The number of floating-point operations in a typical computation is relatively independent of the machine at hand. Of course, MFLOPS don't tell you whether floating-point divisions are ridiculously slow, and they don't tell you how non-floating-point computations will run, but they're at least a bit more solid than MIPS. > I would also like to know why companies are using MIP ratings for those machine > s if they are not accurate. If you were trying to make a machine look good, you'd take the most favorable measurement you could get, right? (I don't actually have a 5000-MIP Turing machine, btw.) ---Dan
kludge@grissom.larc.nasa.gov ( Scott Dorsey) (03/14/91)
In article <3516:Mar1319:50:3291@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >In article <645@ssdc?> jbasara@ssdc (jim basara) writes: >> Could someone please >> provide me with a descriptive explaination of why MIP ratings are not a >> good way of comparing processing speed for RISC machines as opposed to MFLOPS? > >I've got this Turing machine that runs at 5000 MIPS. That's right, it >can move the tape back and forth 5 *billion* times a second. Impressed? >You shouldn't be: it takes so many instructions to get something done on >a Turing machine that the MIPS measurement is pointless. Actually, I do have a machine with a single instruction (subtract and skip if borrow) that I built as a project for a computer architecture class. It runs at about 220 MIPS because it has no instruction decode time, but it isn't very efficient at all. This is one of the reasons that MIPS is a totally useless measure ("Meaningless Index Promoted by Salesmen"). The other problem that we come to is that with the new RISC machines, the actual MIPS ratings are exceedingly high, much more so than the performance would indicate if you used CISC processors as a baseline. If you printed them, people wouldn't believe them, so the marketing people came up with MIPS-equivalent numbers. VUPS for example ("Very Useless Promotional Specification") is supposed to measure the compute power of a machine in terms of 11/780's. It's calculated differently by every company, and is often promoted as being a "MIPS" number. MIPS and MFLOPS are both utterly useless because they don't have any information about the instruction mix. I can execute a program full of NOPs a lot faster than a program full of DIVs, and that's okay. Your instruction mix won't be the same one the marketing folks use, I can assure you. Intel takes n benchmarks, averages the result, and points out how much faster their machine is over some other machine. But then, they don't have a very realistic mixture of tasks in their benchmarks, and each benchmark is not weighted to simulate a "typical" job mix. This makes it completely useless. But then, Intel also used to have an ad with a benchmark they had hoked up to run faster on an 8080 than on an IBM 370/168. --scott
mash@mips.com (John Mashey) (03/16/91)
In article <3516:Mar1319:50:3291@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >In contrast, MFLOPS measure some (supposedly) real amount of work >getting done. The number of floating-point operations in a typical >computation is relatively independent of the machine at hand. Of course, >MFLOPS don't tell you whether floating-point divisions are ridiculously >slow, and they don't tell you how non-floating-point computations will >run, but they're at least a bit more solid than MIPS. No they're not .... Read Hennessy & Patterson, page 43-44. The only reason why MFLOPS might sometimes mean something is that if they're (fully-qualified, i.e., FORTRAN, 64-bit) LINPACK MFLOPS, then you are actually talking about performance as measured on a specific benchmark, which is rather different than talking about MFLOPs in As has been discussed numerous times in the past: vendor-published mips-ratings are essentailly meaningless. no single number captures the performance differences among machines. Dhrystone-vax-mips almost always over-predict the performance of modern machiens relative to a VAX-11/780, compared to their performance on realistic programs. So far, the single-mips-related measure that is available for a wide number of machines, and has some consistency and predictive value, in my opinion, is the SPEC-integer subset, because: the 4 programs are enough larger than Dhrystone and such to avoid silly cache effects. (They're still not quite big enough, perhaps). they're real programs, and hard to compiler-gimmick. they're fairly consistent, i.e., the VAX-relative variance is fairly low. (The above are reasonably verifiable. In addition ,they correlate reasonable well with some larger, more stressful, but proprietrary benchmarks that lots of use inside computer companies.) The SPEC FP subset is also useful, although the benchmark-to-benchmark variance is much higher, and hence you need to do more of your own benchmarking to figure out which of yours calibrate with them. (This is the nature of FP programs, in general.) In general, Chapter 2 of Hennessy & patterson is good to read. -- -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 MS 1/05, 930 E. Arques, Sunnyvale, CA 94086
dricejb@drilex.UUCP (Craig Jackson drilex1) (03/17/91)
In article <3516:Mar1319:50:3291@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >In article <645@ssdc?> jbasara@ssdc (jim basara) writes: >> Could someone please >> provide me with a descriptive explaination of why MIP ratings are not a >> good way of comparing processing speed for RISC machines as opposed to MFLOPS? > >I've got this Turing machine that runs at 5000 MIPS. That's right, it >can move the tape back and forth 5 *billion* times a second. Impressed? >You shouldn't be: it takes so many instructions to get something done on >a Turing machine that the MIPS measurement is pointless. This should go in a FAQ list (Frequently Asked Questions) for comp.arch & comp.benchmarks: MIPS (Millions of Instructions Processed per Second) has nothing to do with the number of instructions your machine processes in one second, unless your machine is an IBM 370. The bronzed 1-MIPS standard is a 370/158, I believe. Over 10 years ago, Digital found that the VAX 11/780 had processing power similar to that of the 370/158. They used this information in their marketing literature, and everyone began calling the 11/780 a 1-MIPS machine. Actually, it only processed about 500,000 instructions/second, on average. However, due to the nature of the instructions, it performed about the same work as the 370/158 in a given unit of time, running some set of benchmarks. (Don't ask me what they were; I know this equivalence predated Dhrystone.) Today, when somebody says they have a 25-MIPS machine, it means "processes some benchmark or benchmarks 25 times faster than an 11/780", unless they are in the IBM world. Now, as to why people quote MIPS instead of MFLOPS: Many uses to which a computer can be put do not involve significant floating-point. In particular, in the business processing world where the MIPS measurement originated, floating-point is unusual. Therefore, people care more about the speed of processing a non-floating-point instruction mix. In the scientific world, floating-point is important. The Usenet readership tends to be more oriented towards floating-point computing than the computing community at large. You will find MFLOPS numbers quoted here from time to time. -- Craig Jackson dricejb@drilex.dri.mgh.com {bbn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}
lindsay@gandalf.cs.cmu.edu (Donald Lindsay) (03/18/91)
In article <24780@drilex.UUCP> dricejb@drilex.UUCP (Craig Jackson drilex1) writes: >Today, when somebody says they have a 25-MIPS machine, it means >"processes some benchmark or benchmarks 25 times faster than an >11/780", unless they are in the IBM world. There are lies, damned lies, and benchmarks, to quote the title of an Inmos tech note. However, this enlightened understanding doesn't prevent Inmos from describing a chip as "20 MIPS" when in fact it runs some benchmark 3.5 or 3.7 times faster than a 780. The discrepancy is because they are quoting native MIPS, for a chip typically executing one one-byte instruction per clock. This doesn't mean that Inmos is the sleaziest company around: all boasts of (MIPS == peak native MIPS) are equally sleazy. Cray, at the other end of the spectrum, can get 64 results from a single opcode. Cray boasts about the 64 results, which is reasonable: results are the thing you actually want. Somewhat tricker is the issue of end-to-end results. If a benchmark's inner loop is recoded to have 3 more FADDs and two fewer FMULs, then has the benchmark's FLOPs changed? I would argue that it hasn't. The important thing about a machine is that it can deliver results. I agree with the benchmark designers who take some fixed count of results/FLOPs/Whetstones/etc, divide by the runtime-in-seconds, and call that the results per second. -- Don D.C.Lindsay .. temporarily at Carnegie Mellon Robotics
russb@hpfcso.FC.HP.COM (Russ Brockmann) (03/19/91)
#define slight_drift Scott Dorsey (kludge@grissom.larc.nasa.gov) writes: > The other problem that we come to is that with >the new RISC machines, the actual MIPS ratings are exceedingly high, much more >so than the performance would indicate if you used CISC processors as a >baseline. If you printed them, people wouldn't believe them, so the marketing >people came up with MIPS-equivalent numbers. VUPS for example ("Very Useless >Promotional Specification") is supposed to measure the compute power of a >machine in terms of 11/780's. It's calculated differently by every company, >and is often promoted as being a "MIPS" number. Surprisingly, this isn't necessarily so, at least in some cases. #define toot_horn_mode Case in point: The HP 835 (a RISC machine, and a quite old one at that) has a clock rate of 15 MHz, and can sustain instruction execution rates of about 11 MIPS (native instructions) (footnote 1). But the machine was rated at around 14 VUPS at intro (actually may have been 15, can't remember now). HP used the "conservative" method of using the geometric mean of 15 integer benchmarks compared to a VAX 11/780 (anyone care to dispute that an 11/780 is a CISC machine :~) ). The geometric mean is a much more conservative way of averaging benchmarks than the arithmetic mean. 835 Native MIPS rating (peak): 15 MIPS 835 Native MIPS rating (sustained): 11 MIPS 835 VUPS rating (geom. mean 15 BM's): 14 MIPS So, believe it or not, at least for this one instance, it was actually better for HP to quote VUPS than to quote sustained MIPS. Even to quote the "nop" rate of 15 MIPS wouldn't have grossly misstated the performance. And I don't think this is that uncommon. And now, back to our regularly scheduled program... #undef toot_horn_mode #undef slight_drift On the original question, MIPS are, for the most part, meaningless. The biggest problem is in attempting to quote a single "MIPS" number without knowing what "MIPS" number is meant. But the more a vendor clarifies _how_ he measured his "MIPS," and the more numbers he provides, the better a potential customer is able to determine a particular machines' strengths and weaknesses. Another problem is that RISC machines often depend heavily on very smart compilers to optimize the instructions needed to get a job done. A given machine can actually improve its "MIPS" rating over time as compilers get smarter. Note that MFLOPS ratings suffer from a slightly less widely known malady. Most chip vendors will quote their peak MFLOPS, which can be a very special case of highly tailored, pipelined operations with numerous assumptions. Most computer vendors tend towards Linpack MFLOPS, which can be compiled or hand-coded to varying degrees, and can be single- or double-precision. This, however, isn't always the case. A vendor may quote a peak rate of inline, non-interlocking FADDS. Or if his hardware supports parallel FADD/FMULT, he can quote an even higher number. This isn't all bad, as long as you know what the number means. A recent trend is to provide many numbers, including SPECmarks, Drystone MIPS, Linpack SP/DP MFLOPS, Whetstones, VAX MIPS, Khornerstones, IOstones, Xstones(?), and a plethora of other benchmark suites. Many manufacturers are now trying to be more careful to specify exactly how they measured the numbers, enough so that the numbers can be duplicated by the customer. This is a positive trend in my opinion, and makes it possible to make limited judgements on the performance of a machine. It's still dangerous, but with care, all "MIPS" numbers are not totally meaningless. MIPS or MFLOPS, by themselves, are incomplete units of measure, somewhat akin to saying $100.00 without saying whether it's US or Canadian. As always, the best test is to run the machines through the kind of workload you intend to use them for. #define nitpick MIPS (Million Instructions Per Second), not MIP (Million Instructions Per ?) MFLOPS (Million FLoating point Operations Per Second) not MFLOP... #undef nitpick -- Russ Brockmann russb@hpfcso.HP.COM (303)229-2489 Disclaimer: echo $MY_OPINIONS >/dev/null -------- footnote 1: J.D. Yetter, et al, "A 15MIP 32-Bit Microprocessor," Digest of Technical Papers, International Solid State Circuit Conference, February 1987. "/tmp/nfa08784" 96 lines, 4455 characters
gould@pilot.njin.net (Brian Jay Gould) (03/19/91)
There was a question a few years ago about what is the fastest computer... Fortunately, we were able to get away with the explanation that all system performance is very application dependent. In fact, some of the best CPU performers are so poorly balanced in I/O and other features that they benchmark behind slower CPU's. The same applies to supercomputer architectures where a system mey work well with very large vectors but has such a high latency that most scalar applications show up as slower than a PC. The only real way to measure the speed of a system is to drop it from a building and calculate 42 feet per second squared. -- -- Any disclaimers made for me, by me, or about me - may or may not accurately reflect my failure to be reflecting the opinions of myself or anyone else. ************************************************* * Brian Jay Gould - Professional Brain-stormer * *************************************************
jeff@unicorn.cc.wwu.edu (Jeff Wandling) (03/19/91)
gould@pilot.njin.net (Brian Jay Gould) writes: [..stuff deleted..] >The only real way to measure the speed of a system is to drop >it from a building and calculate 42 feet per second squared. Turns out that this is faster than some of the first IBM RS/6000 520's in multi-user mode. :-) :-) :-) -- Jeff Wandling jeff@unicorn.cc.wwu.edu
barmar@think.com (Barry Margolin) (03/19/91)
In article <Mar.18.21.39.27.1991.17252@pilot.njin.net> gould@pilot.njin.net (Brian Jay Gould) writes: >The only real way to measure the speed of a system is to drop >it from a building and calculate 42 feet per second squared. Wow, that's a fast computer! I don't even expect the Connection Machine to do better than 32 f/s^2. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
john@IASTATE.EDU (Hascall John Paul) (03/19/91)
In article <1991Mar19.052828.20842@Think.COM>, barmar@think.com (Barry Margolin) writes: > In article <Mar.18.21.39.27.1991.17252@pilot.njin.net> gould@pilot.njin.net (Brian Jay Gould) writes: > >The only real way to measure the speed of a system is to drop > >it from a building and calculate 42 feet per second squared. > > Wow, that's a fast computer! I don't even expect the Connection Machine to > do better than 32 f/s^2. Of course, that's ((32 f/s^2) * N-processors) for a truly amazing MIPS rating (Meaningless Index of Plummeting Speed) ;-) Maybe we need a fhallingStones benchmark? -- John Hascall An ill-chosen word is the fool's messenger. Project Vincent Iowa State University Computation Center john@iastate.edu Ames, IA 50011 (515) 294-9551
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (03/20/91)
In article <Mar.18.21.39.27.1991.17252@pilot.njin.net> gould@pilot.njin.net (Brian Jay Gould) writes: | The only real way to measure the speed of a system is to drop | it from a building and calculate 42 feet per second squared. On what planet? -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "Most of the VAX instructions are in microcode, but halt and no-op are in hardware for efficiency"
mikeg@c3.c3.lanl.gov (Michael P. Gerlek) (03/20/91)
In article <1991Mar19.090929@IASTATE.EDU> Hascall John Paul writes: > > Of course, that's ((32 f/s^2) * N-processors) for a truly amazing > MIPS rating (Meaningless Index of Plummeting Speed) ;-) > > Maybe we need a fhallingStones benchmark? So *that's* why Crays are so fast - they're designed to be areodynamically more efficient than your basic clunky, box-shaped machines! Adds a whole new dimension to the idea of "computer architecture"... We now return you to your regularly scheduled shell-globbing discussion. -[mpg] mikeg@lanl.gov "Wind-tunnels: they're not just for airplanes anymore." -- -[mpg] mikeg@lanl.gov "Back to bed / Back to reality..."
johnz@pta.oz.au (John Zornig) (03/20/91)
In article <1991Mar19.090929@IASTATE.EDU>, john@IASTATE.EDU (Hascall John Paul) writes: > > Maybe we need a fhallingStones benchmark? > I vote for the DropStone, This would be calculated as the terminal velocity of a computer system freefalling from a great height. Attempts to reduce air resistance by removing peripheral cabinets and monitors are not allowed. A standard drop height should be agreed by having two separate industry standards bodies select different heights and then see who can get the most press. Of course the poor enduser who cannot afford to destroy $$$ worth of equipment, or afford to hire a crane, plane, room on the space shuttle etc. may opt for pushing the system under test off a desktop. I speak for no one. JZ
gary@proa.sv.dg.com (Gary Bridgewater) (03/20/91)
In article <1991Mar19.090929@IASTATE.EDU> john@IASTATE.EDU (Hascall John Paul) writes: >In article <1991Mar19.052828.20842@Think.COM>, barmar@think.com (Barry Margolin) >writes: >> In article <Mar.18.21.39.27.1991.17252@pilot.njin.net> gould@pilot.njin.net >(Brian Jay Gould) writes: >> >The only real way to measure the speed of a system is to drop >> >it from a building and calculate 42 feet per second squared. >> >> Wow, that's a fast computer! I don't even expect the Connection Machine to >> do better than 32 f/s^2. > > Of course, that's ((32 f/s^2) * N-processors) for a truly amazing >MIPS rating (Meaningless Index of Plummeting Speed) ;-) I assumed that was Virtual feet per second using a gravity cache. > Maybe we need a fhallingStones benchmark? The first benchmark with a theme song - "Listen to the rhythm of the ...". -- Gary Bridgewater, Data General Corporation, Sunnyvale California gary@sv.dg.com or {amdahl,aeras,amdcad}!dgcad!gary C++ - it's the right thing to do.
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (03/20/91)
In article <5644@pta.oz.au> johnz@pta.oz.au (John Zornig) writes: | I vote for the DropStone, This would be calculated Surely you mean dhropstone. A benchmark without an 'h' would never fly (I didn't say that, did I?). -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "Most of the VAX instructions are in microcode, but halt and no-op are in hardware for efficiency"
tim@netcom.COM (Tim Richardson) (03/21/91)
In article <1991Mar19.033409.1093@unicorn.cc.wwu.edu> jeff@unicorn.cc.wwu.edu (Jeff Wandling) writes: ==gould@pilot.njin.net (Brian Jay Gould) writes: == ==>The only real way to measure the speed of a system is to drop ==>it from a building and calculate 42 feet per second squared. == =Turns out that this is faster than some of the first IBM RS/6000 520's in =multi-user mode. :-) :-) :-) = = Jeff Wandling = jeff@unicorn.cc.wwu.edu Programed with heavy metal components. -- Tim Richardson email: tim@netcom.com {apple, amdahl, claris}!netcom!tim ******************************************************************************* "Those willing to give up a little liberty for a little security deserve neither security nor liberty". ------ Benjamin Franklin *******************************************************************************
raj@hpindwa.cup.hp.com (Rick Jones) (03/21/91)
>>The only real way to measure the speed of a system is to drop >>it from a building and calculate 42 feet per second squared. > >Wow, that's a fast computer! I don't even expect the Connection Machine to >do better than 32 f/s^2. > Perhaps it was using an FPA - Falling Processor Accelerator. groan ;-) rick jones
bernie@metapro.DIALix.oz.au (Bernd Felsche) (03/24/91)
In <5644@pta.oz.au> johnz@pta.oz.au (John Zornig) writes: >In article <1991Mar19.090929@IASTATE.EDU>, john@IASTATE.EDU (Hascall John Paul) writes: >> >> Maybe we need a fhallingStones benchmark? >> >I vote for the DropStone, .... I think you mean "DhropStone", don't you? -- Bernd Felsche, _--_|\ #include <std/disclaimer.h> Metapro Systems, / sale \ Fax: +61 9 472 3337 328 Albany Highway, \_.--._/ Phone: +61 9 362 9355 Victoria Park, Western Australia v Email: bernie@metapro.DIALix.oz.au
steve@robobar.co.uk (Steve Bleazard) (03/26/91)
davidsen@crdos1.crd.ge.com (bill davidsen) writes: > In article <Mar.18.21.39.27.1991.17252@pilot.njin.net> gould@pilot.njin.net (Brian Jay Gould) writes: > > | The only real way to measure the speed of a system is to drop > | it from a building and calculate 42 feet per second squared. > > On what planet? You know of buildings on other planets? Tell me more! Steve -- Steve.Bleazard@RoboBar.Co.Uk | Phone: +44 81 991 1142 x153 Snr Software Engineer, Robobar Ltd. | Fax: +44 81 998 8343 (G3) 22 Wadsworth Road, Perivale. | Middx., UB6 7JD ENGLAND. | ...!ukc!robobar!steve
firth@sei.cmu.edu (Robert Firth) (03/26/91)
In article <Mar.18.21.39.27.1991.17252@pilot.njin.net> gould@pilot.njin.net (Brian Jay Gould) writes: >The only real way to measure the speed of a system is to drop >it from a building and calculate 42 feet per second squared. Not on this planet, i fear.