wes@harem.clydeunix.com (Wes Peters) (05/06/91)
In article <309@raysnec.UUCP>, shwake@raysnec.UUCP (Ray Shwake) writes: > Great. You've shown that a 486/25 can run Dhrystones and short loops > under elk as well as a SparcStation 1+. Is *that* what you do all day? Has it > occurred to you that these tests, and others of their ilk, provide only the > crudest indication of relative performance? Well, consider it. How tragic > that, as hardware, operating environments and applications have become more > sophisticated, people still give credence to such quick-and-dirty > measurements. When I was in college, we developed a simple benchmark for microcomputers that still holds true for workstations today, for the software development work that I do: 1- kermit the source code for Dave Betz' public-domain Lisp interpreter to the machine (if it can't run kermit, something is seriously wrong with it :-) 2- make the lisp executable, note the time. This is benchmark time #1. 3- run the lisp program. Type in a simple routine to calculate factorials using tail recursion. Calculate 69!, note the time. This is benchmark time #2. This isn't the be-all, end-all of benchmarks, but it does give you some idea of how fast the system can compile and link, and some idea of the integer performance. For software development, the only other test I can think of is 'Does it have a good editor?' Replace 'good editor' with the name of your favorite. Of course, the best benchmark is to spend a week or two doing what you normally do with the machine under test. This will give you a REAL good idea how well the machine will perform ASAP. Wes Peters -- #include <std/disclaimer.h> The worst day sailing My opinions, your screen. is much better than Raxco had nothing to do with this! the best day at work. Wes Peters: wes@harem.clydeunix.com ...!sun!unislc!harem!wes