Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!wuarchive!decwrl!ucbvax!hplabs!otter!gjh
From: gjh@otter.hpl.hp.com (Graham Higgins)
Newsgroups: comp.sys.atari.st
Subject: GCC times(2) & #define HZ tech query
Message-ID: <570049@otter.hpl.hp.com>
Date: 8 Dec 89 12:38:37 GMT
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Lines: 75

Can anyone enlighten me on the following technical query?

The C system call "times(2)" -- my SysV manual states:

"The times are in units of 1/HZ seconds, where HZ is processor dependent (see
<sys/param.h>)."

The sys/param.h from J.Bammi's port of GCC to the ST doesn't have a definition
for HZ.

My local Sun's sys/param.h file defines it as:

#define HZ      60              
/* ticks/second according to syscalls that return values in ticks */

My HP9000/350 defines it as:

#define HZ      50              
/* Ticks/second of the clock (in kernel land) */

Can anyone provide me with an appropriate value for HZ for an (unaccelerated)
ST?

Background ...

I have a Prolog benchmark indicating a (literally) incredibly slow ST
performance level and here there's a caveat, the benchmark README file contains
the following warning:

    WARNING: Naive reverse is the classical benchmark for
             computing "LIPS" (Logical Inferences Per Second),
             but it's such a small benchmark that LIPS numbers
             so obtained may not necessarily reflect overall system
             performance, and should be taken with a large pinch of salt.


*However* -- on my HP9000/350, the same benchmark (run by the same Prolog)
indicates a performance level of 30KLips whereas the ST can apparently run only
1.5KLips!. I was surprised at (and suspicious of) the size of the difference in
apparent performance. I know they said "should be taken with a large pinch of
salt", but this requires a cartload!

Crude stopwatch timing indicates that the ST performs the benchmark in ~40
secs, the HP9000/350 in ~10 secs. From those crude timings, the ST benchmark
indicator should be around 5 to 6KLips, not 1.5KLips. So, perhaps a problem
with times(2) ??

The Prolog is SUNY/UArizona's StonyBrook Prolog, GCC-cross-compiled to ST. The
benchmark relies upon a "cputime" function ---

    int msec;
    struct tms t;
    times(&t);
    msec = t.tms_utime * 1000 / 60;

which is supposed to return the cpu time in millseconds. 

Can anyone tell me is this appropriate for GCC for the ST? --- it *looks*
plausible, but the times don't seem to pan out properly? 

If I can fix this, I'll make the ST port of Stony Brook Prolog available.

Cheers,

Graham
======

------------------------------------------------------------------
Graham Higgins             	|  Phone: (0272) 799910 x 24060
Hewlett-Packard Labs    	|  gray@hpl.hp.co.uk
Bristol                       	|  gray%hplb.uucp@ukc.ac.uk
U.K.                          	|  gray@hplb.hpl.hp.com
------------------------------------------------------------------
Disclaimer: My opinions above are exactly that, mine and opinions.
------------------------------------------------------------------