optimum value of cpu time/clock time. 
Author Message
 optimum value of cpu time/clock time.

Hi,
              Is there any optimum value of CPU time/clock time for
efficient application?As we all know higher CPU time/clock time mean
bad subroutine call or coding practice whereas lower CPU time/clock
time mean bad I/O practice or bad database/file access method.

Thnaks and Warm Regards.
shyam
********************************************************************************



Thu, 08 Jul 2004 14:57:22 GMT  
 optimum value of cpu time/clock time.

Quote:
> ......As we all know higher CPU time/clock time mean
> bad subroutine call or coding practice whereas lower CPU time/clock
> time mean bad I/O practice or bad database/file access method.

As we all know? you need to correct that, to,  " as we all (except Mattias)
know..."

That is a rather broad statement. Seems to me "clock time" is going to be
affected by the number of jobs running, assigned queue priorities and a host
of other issues totally unrelated to coding style.

That is, "clock time" would to me seem totally irrelevant as a factor in
analyzing the "performace" of applications.

--
Michael Mattias
Tal Systems, Inc.
Racine WI



Fri, 09 Jul 2004 00:00:44 GMT  
 optimum value of cpu time/clock time.
Really?  Without any regard to what is being done?  You mean if I run ten
trasactions through a program, and it takes 10 seconds, then run 100
transactions and it takes 50 seconds that is poorer performance?   CPU time
is a measuement of how many CPU cycles a process took.  It does not "mean"
anything.  It is a number, one bigger than the number before it, and one
less than the number after it.  Any meaning beyond taht is inflicted on the
poor thing from outside.

Donald


Quote:
> Hi,
>               Is there any optimum value of CPU time/clock time for
> efficient application?As we all know higher CPU time/clock time mean
> bad subroutine call or coding practice whereas lower CPU time/clock
> time mean bad I/O practice or bad database/file access method.

> Thnaks and Warm Regards.
> shyam

****************************************************************************
****


Fri, 09 Jul 2004 01:06:28 GMT  
 optimum value of cpu time/clock time.

"shyam nivas" <

Quote:
> Hi,
>               Is there any optimum value of CPU time/clock time for
> efficient application?As we all know higher CPU time/clock time mean
> bad subroutine call or coding practice whereas lower CPU time/clock
> time mean bad I/O practice or bad database/file access method.

I've always relied on 42.


Fri, 09 Jul 2004 06:20:56 GMT  
 optimum value of cpu time/clock time.

Quote:

> Hi,
>               Is there any optimum value of CPU time/clock time for
> efficient application?As we all know higher CPU time/clock time mean
> bad subroutine call or coding practice whereas lower CPU time/clock
> time mean bad I/O practice or bad database/file access method.

> Thnaks and Warm Regards.
> shyam
> ********************************************************************************

I have no real idea what you are talking about. Other
posters to this have given answers, but I don't think they
know what you are talking about either.

What exactly are you trying to do, or figure out? Without
knowing this, the statement(s) you gave sound almost like
they were taken out of context from a text book.

--
Steve Thompson
VS Strategies
330/335-9907 office
 Notice: By sending SPAM (UCE/BCE) to this address, you are
accepting and agreeing to our charging a $1000 fee, per
email, for handling and processing, and you agree to pay any
and all costs for collecting this fee.



Fri, 09 Jul 2004 10:36:59 GMT  
 optimum value of cpu time/clock time.
Shyam,

This is simply nonsense.

A higher CPU time/clock time does NOT (necessarily) indicate a "bad
subroutine call" (whatever that means...I don't see how a call to subroutine
can be good or bad, any more than it can be happy or sad or interested or
bored. It either succeeds or it doesn't, emotions and morals are not a
consideration... ). Neither does it (necessarily) mean "bad coding
practice".  It CAN be an INDICATOR of these thngs, but only by investigation
and examination can it be confirmed that there is, indeed, a problem.

The second part of your statement is even worse...

"...whereas a lower CPU time/clock time means bad I/O practice or bad
datbase/file acess method"

It indicates NO such thing. It simply indicates that there is not a lot of
work for the CPU to do when accessing this particular data. Normally this is
viewed as a desirable state of affairs and certainly not a cause for
castigating the DBA... (there are enough REAL causes for this without
inventing imaginary ones...<G>).

I don't know where you picked up these ideas or who has been filling your
head with such rubbish. Start thinking for yourself and you will realise the
absurdity of it.

To try and establish the validity of these claims with the old "Everyone
knows..." chestnut is perhaps the worst folly of all... You will find that
"Everyone knows" no such thing... Most people here, for instance, will
distance themselves from what you wrote.

So, to answer your question:

The OPTIMUM value of cpu time/clock time is 42.

Or 31.

Or 57...

Or possibly, the same value as the percentage of  milk to oatmeal in my
breakfast this morning... or the number of cracks in the pavement you
stepped on, on your way to work/school....

It is a number which, in and of itself, has no meaning or relevance.

Pete.


Quote:
> Hi,
>               Is there any optimum value of CPU time/clock time for
> efficient application?As we all know higher CPU time/clock time mean
> bad subroutine call or coding practice whereas lower CPU time/clock
> time mean bad I/O practice or bad database/file access method.

> Thnaks and Warm Regards.
> shyam

****************************************************************************
****

 Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
    ** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------        
                http://www.usenet.com



Fri, 09 Jul 2004 13:58:28 GMT  
 optimum value of cpu time/clock time.

:>              Is there any optimum value of CPU time/clock time for
:>efficient application?As we all know higher CPU time/clock time mean
:>bad subroutine call or coding practice whereas lower CPU time/clock
:>time mean bad I/O practice or bad database/file access method.

Not at all.

A report program against a huge file will use very little CPU but a lot of
elapsed.

Conversely, a code-cracking program will use a lot of CPU but little I/O.

--

http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel



Fri, 09 Jul 2004 14:05:13 GMT  
 optimum value of cpu time/clock time.

Quote:
> The OPTIMUM value of cpu time/clock time is 42.

Isn't 42 also the meaning of life, the universe, and everything?
Mike


Fri, 09 Jul 2004 14:29:01 GMT  
 optimum value of cpu time/clock time.

Quote:
> > The OPTIMUM value of cpu time/clock time is 42.

> Isn't 42 also the meaning of life, the universe, and everything?

Precisely.

And there is Apochryphal evidence that Deep Thought was programmed  by mice
on the Indian Sub-Continent ...

As Dame Edna would say..."Spooky, Possums, spooky...!"

Pete.

 Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
    ** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------        
                http://www.usenet.com



Fri, 09 Jul 2004 21:44:18 GMT  
 optimum value of cpu time/clock time.

Quote:
>>>>>>>>>>>>>>>>>> Ursprngliche Nachricht <<<<<<<<<<<<<<<<<<


nivas) zum Thema optimum value of cpu time/clock time.:

Quote:
> Hi,
>               Is there any optimum value of CPU time/clock time for
> efficient application?As we all know higher CPU time/clock time mean
> bad subroutine call or coding practice whereas lower CPU time/clock
> time mean bad I/O practice or bad database/file access method.

In my past and experience i found a good time between cpu and
duration:

one cpu-second aprox one minute clock time

if this is quite good, down to 40 Seconds and up to 1 minute 20, i dont
take a look to tune the job. If ist more (1 CPU-second > 2 Minutes), i
must do something in i/o Prozessing, if it's less (10
CPU-Seconds/Minute) i must look upon routines

The use of tools like OMEGAMON, Strobe or anythink else is
recommended!

Have a nice day

Andreas Lerch



Sat, 10 Jul 2004 02:19:27 GMT  
 optimum value of cpu time/clock time.

...

Quote:
>               Is there any optimum value of CPU time/clock time for
> efficient application?As we all know higher CPU time/clock time mean
> bad subroutine call or coding practice whereas lower CPU time/clock
> time mean bad I/O practice or bad database/file access method.
> Thnaks and Warm Regards.
> shyam

The optimum CPU time is no more than is needed for the process at hand;
the optimum number of I/O's is the minimum required to access/update the
data required by the process.  That said, the ratio of
CPU-time/clock-time really has no general correlation with efficiency.
A process that must read millions of records with minimal processing may
be the best possible with a very low CPU/clock ratio because it is
heavily I/O bound;  a perfectly designed algorithm with I/O minimized
and completely overlapped with CPU may be ideal with a CPU/clock ratio
of 1.0, or higher if it uses multi-tasking (and whether it can achieve
that ratio may be completely dependent on competition for the CPU with
other concurrently running programs, and not on any inherent merit of
that particular application).  If you upgrade to a faster CPU, or if you
upgrade to faster DASD, you change the balance between CPU and I/O and
alter the CPU/Clock ratio for existing applications; yet, there has been
no real change in the "efficiency" of the application.

The questions you instead should be asking are "can I choose a different
algorithm for the process that involves less computation (or perhaps
even redefine the process itself, if you have that flexibility)?", "can
I reduce the number of records my program needs to read by using a
different algorithm, or a different file/record organization?", or "can
I in some way tune the execution of the program to improve the
efficiency of reading/updating records?"  In the later case that tuning
could involve using different buffering techniques or more buffers,
redefining the file or data base with additional indexes, organizing the
file or data base differently, etc.

Invariably, the largest decreases in CPU time come from choosing a
better algorithm, although any tuning that significantly reduces the
number of physical I/O operations required can also significantly reduce
CPU time.  I have seen cases under OS/390 where aggressive buffering on
KSDS VSAM files cut  physical I/O from several million down to a few
thousand, and cut the CPU by a factor of 10 or better.  There may be
some pathological cases where the specific implementation of an
algorithm becomes significant if it uses some language feature that is
particularly inefficient, but these are usually secondary issues.  When
DataBase queries are involved, CPU can also be heavily influenced by
using more efficient query formulations or better indexing, as this can
greatly reduce the number of physical records that must be processed to
satisfy the query.

Invariably, the largest decreases in elapsed time come from
significantly reducing the number of physical I/O operations involved.
For a given file structure, the optimum number of I/O's is to read each
block containing needed information only once, to write each block
containing information that must be updated once, to block reads and
writes of consecutive blocks together in a single I/O operation where
possible, and to touch no unneeded blocks.  Whether this is achievable
depends on what buffering and access techniques are available to you,
which may also depend on whether the file is concurrently shared.  If
you have an indexed file structure with only 500 blocks and you are
performing millions of I/O's to the file, this is obviously worth
investigating!

In a real production environment there are many applications that are
sub optimal.  You don't generally have the luxury of dealing with
performance/efficiency considerations unless the application is a
problem area:  you are forced to deal with these issues when (1) the
application needs CPU or I/O resources at a time they are in short
supply, (2) the application is using more resources than the user is
willing to pay for, (3) the application is unable to complete within
required deadlines, of (4) the application is using resources in a way
that adversely affects the system throughput and/or other users of the
system.  Applications that are not perceived to be a problem are left
alone in order to have time to deal with those that are.
--



Sat, 10 Jul 2004 10:31:38 GMT  
 
 [ 11 post ] 

 Relevant Pages 

1. cpu time VS. calendar time

2. HELP:Measuring CPU time and elasped time of FORTRAN77

3. Why is time.clock() returning negative float values (on 64bit Digital UNIX Alpha)

4. The time value of time

5. Bug in time.c (was Time.times problems)

6. time and scheduling (was: bug report: [ #447945 ] time.time() is not non-decreasing)

7. time zones, daylight saving time, and universal time

8. sampling waveform values and writing corresponding time values

9. Help: CPU Time

10. Eating CPU time on NT

11. *** CPU Time Slice Program ***

12. CPU-Time = 100%!

 

 
Powered by phpBB® Forum Software