chris@mimsy.umd.edu (Chris Torek) (10/18/90)
In article <34815@cup.portal.com> ts@cup.portal.com (Tim W Smith) writes: >... I've tried a couple of these on my Mac II, using Think C. Note >that 1) Apple is not noted for squeezing the last drop of performance >out of the 68020, and 2) Think C has not stressed optimal code generation. >I get [... numeric value deleted, but] the Sun is getting ... >20 times worse performance. [Why?] Two obvious possibilities: you may have been running the buggy version of the tests (no value returned from bigrand()), or---more likely--- you have a System V machine with no reasonable way of obtaining CPU resource usage. (This is not to say that no System V machine has a reasonable facility a la getrusage().) The `times' call used in the original bit-counting program returns time values in `clock ticks'. There is no reliable way to discover how long a `clock tick' is. It is often 1/60th of a second, but often 1/50th or 1/100th or some other value. On some system you can `#include <sys/param.h>' and get a manifest constant called `HZ' that tells you the default divisor for 1---that is, the number such that HZ ticks elapse every second---but this is merely the default; the actual running system might be using some other value (and might even change it `at whim', so to speak). On other systems you can fish the actual value of hz out of the system. The method is highly machine-dependent, and may give you the wrong answer (e.g., under Ultrix on a DECstation 3100, hz is normally 256, yet the values from times() are always in 1/60th of a second, because times() is actually implemented using getrusage() with a hardcoded `60 hz' inside the times() function.) This is why I put the getrusage() call into the program. getrusage() fills in a machine- and system-independent structure with values in seconds and microseconds. The microseconds field is typically inaccurate (being a step function with a grain other than 1), but its units are known, unlike those for times(). If you have a BSD-based system, the values reported by the timing function in the bit-count timing program have some chance of being useful; if not, they are much more chancy. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 405 2750) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris