NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/bit/listserv/sasl/5593

Text File | 1993-01-12 | 3.6 KB | 73 lines

Comments: Gated by [e-mail]
Path: sparky!uunet!europa.asd.contel.com!howland.reston.ans.net!zaphod.mps.ohio-state.edu!malgudi.oar.net!news.ysu.edu!psuvm!auvm!VCUMVS.BITNET!RIKARD
Message-ID: <[e-mail]>
Newsgroups: bit.listserv.sas-l
Date:         Tue, 12 Jan 1993 17:19:05 -0500
Reply-To:     [e-mail]
Sender:       "SAS(r) Discussion" <[e-mail]>
From:         [e-mail]
Subject:      REAL vs CPU Time
Lines: 61

O boy, o boy, o boy!!!! We are doing benchmarking again.

Sorry, I just couldn't pass it up.

User response time is a really good measure. It is real important to
the user and fairly understandable. "I started this stuff and got
back an answer real quick like."

Quantifying user response time is real difficult. SAS appears
to be reporting as REAL TIME the amount of wall clock time that
elapsed from beginning to end of the SQL or DATA step. If you
are running standalone (you and only you are using the machine)
(the SAS task, the one and only task used by you running alone)
then REAL TIME is it. If you are using a machine that has any
multi-use capability then REAL TIME is only real for this run,
this day, this time. CPU time becomes a much better measure
for comparison purposes. Note that from the messages sent so far,
we don't know whether either system used is multi-tasking, so
I have no way of judging whether the measures are useful or not.

Claiming that SQL is better than the data step is also very
system dependent. If I have two datasets that are indexed
AND have memory to hold both indexes AND the index happens to be
the selection criteria then an SQL table match should run much
faster than the equivalent one-by-one match merge process
in a datastep. If one of the ANDs isn't true then my wonderful
superquick SQL may become very slow.

My favorite benchmark is the test stream sent with sas/pc 6.02.
Add a data step at the beginning to capture current wall clock
time and one at the end to capture wall clock time again
and subtract the two and Bingo I have user response time. I
can run this on various machines and get response time. I can
run it on a multi-use machine in busy and non-busy times and
get guesstimates for response time. It uses Base and Stat and
nothing else as I recall, so it runs on most SAS installations
that I see. The only problem is it is too short for newer faster
machines. But it was very useful to tune SAS on pc sized
machines (co-processor, disk speed, ram caches, ems memory,...)
trying to find the best general response time. BUT it
was only A measure that was sometimes useful.

A test suite for SAS that provided useful measures would be
a large number of SAS things that test CPU, memory, disk,
math co-processor response characteristics and report a large
number of statistics. This would have to be tightly allied
with the machine characteristics (size of disk, memory, bus speed)
to produce a large table. Then you would need a lot of time
to try to interpret the information. (and I don't personally
think it would be useful information).

I used to say send flames to Bob Hamer and sensible reponses to
me, but Bob asked me not to do that. So send flames to me (not to
SAS-L) and useful remarks to me or SAS-L.

******************************************************************
 Pete Rikard                        Bitnet RIKARD@VCUMVS
 VCU Computer Center                Phone [phone]
 110 S. 7th St, 4th Floor           FAX [phone]
 Richmond, VA 23219                 Internet [e-mail]
******************************************************************