what does the output of 'time' (unix) mean?
Patrick
I am measuring execution time of a program using the 'time' command
(time programname) under unix. As a result, I get 3 different mesures
(user, sys, real), and I am not sure what each of these means. I read
the man on time, and I looked on the internet, and here is where I
got:
real: 'wall' clock time (in my case: 290 s)
user: CPU time spend in user mode (64.45 s)
sys: CPU time spend in system mode (45.29 s)
I think I understand the 'real' time, it is the execution time I can
measure using a stopwatch. It depends on the number of user on the
station, so for the same job, and can be quite variable depending on
the other people.
But I don't really see get the meaning of 'user' and 'sys':
1) what exactly is CPU time? I suppose it is the time the processor is
active on my program, but I don't know which operations this
includes....As an evidence, I guess it is active for all the
calculations that are made. But is there anyting else?
2) does any of these measures take into account the time spent writing
to disk for i/o or scratch files? In fact, this is very important to
me, as I am working an old fortran program in order to remove the
temporary files (and there are lots of them..)
3) if I want to compare execution speed of different versions of my
program (original code vs code with some of the scratch files
removed), which time should I compare?
Thanks for your help
Pat
Arjen Markus
>
> Hello,
>
> I am measuring execution time of a program using the 'time' command
> (time programname) under unix. As a result, I get 3 different mesures
> (user, sys, real), and I am not sure what each of these means. I read
> the man on time, and I looked on the internet, and here is where I
> got:
>
> real: 'wall' clock time (in my case: 290 s)
>
> user: CPU time spend in user mode (64.45 s)
>
> sys: CPU time spend in system mode (45.29 s)
>
> I think I understand the 'real' time, it is the execution time I can
> measure using a stopwatch. It depends on the number of user on the
> station, so for the same job, and can be quite variable depending on
> the other people.
>
> But I don't really see get the meaning of 'user' and 'sys':
>
If I understand it all correctly, then 'user' time is the time spent
by the processor in "user mode", and 'sys' time is the time spent
in "kernel mode". Depending on your purposes, the sum will probably
be the most useful, as that tells you the minimum time needed.
Regards,
Arjen
Jim Carlson
I've also been wondering about this. I've filled in what I know, but
hopefully someone else can help us out.
> 1) what exactly is CPU time? I suppose it is the time the processor is
> active on my program, but I don't know which operations this
> includes....As an evidence, I guess it is active for all the
> calculations that are made. But is there anyting else?
I would like to second this question. What operations (on Unix/Linux,
say) count towards user vs. sys, and what is reflected only in real
time? I believe that sys type is cycles spent in kernel code (?), user
time is cycles spent in your own code, and (real - (user + sys)) is
latency (of IO, for instance) + time spent on other processes. Is this
right? In particular, is the latency of reading and writing from/to RAM
get figured into user/sys? On win32, when I run Cygwin bash's time
command, I tend to see huge differences between user+sys and real, which
I think (based on some experiments) are coming from latency of accessing
RAM. Any chance this is correct?
> 2) does any of these measures take into account the time spent writing
> to disk for i/o or scratch files? In fact, this is very important to
> me, as I am working an old fortran program in order to remove the
> temporary files (and there are lots of them..)
I'm fairly certain disk i/o time will not affect sys or user time, but
it will be part of real time.
> 3) if I want to compare execution speed of different versions of my
> program (original code vs code with some of the scratch files
> removed), which time should I compare?
It sounds like real time is your best measure. Just try to be certain
that all else is held equal during comparisons (e.g., no other users
logged in, as few background processes as possible, etc.).
Jim
Corné Beerse
>
> I am measuring execution time of a program using the 'time' command
> (time programname) under unix. As a result, I get 3 different mesures
> (user, sys, real), and I am not sure what each of these means. I read
> the man on time, and I looked on the internet, and here is where I
> got:
>
> real: 'wall' clock time (in my case: 290 s)
That is finish-time minus start-time. also know as the time you waited
for the finish of the program.
>
> user: CPU time spend in user mode (64.45 s)
The number of seconds your process got cpu cycles to be processed
>
> sys: CPU time spend in system mode (45.29 s)
The number of seconds the system (kernel) spend on behalf of your
process.
>
> I think I understand the 'real' time, it is the execution time I can
> measure using a stopwatch. It depends on the number of user on the
> station, so for the same job, and can be quite variable depending on
> the other people.
Right. (except, the number of users does not count, its their processes
that count. If they don't do anything, they don't consume cpu.)
>
> But I don't really see get the meaning of 'user' and 'sys':
>
> 1) what exactly is CPU time? I suppose it is the time the processor is
> active on my program, but I don't know which operations this
> includes....As an evidence, I guess it is active for all the
> calculations that are made. But is there anyting else?
Unix is a multi tasking system: it does more than just your job. It is
the time actually spend on your task.
>
> 2) does any of these measures take into account the time spent writing
> to disk for i/o or scratch files? In fact, this is very important to
> me, as I am working an old fortran program in order to remove the
> temporary files (and there are lots of them..)
Most i/o (if not all) is done by the system/kernel. The actual time
spend on behalf of your job is in the sys time.
The actual time writing to disk is most likely not in the measurements
since it most likely does not use cpu cycles. The handling of the
buffers an other administrative tasks around disk-i/o does consume cpu
and is accounted for in the sys cpu cycles.
example: if your process reads from tape, you can see your process in a
state of waiting-for-io. (use `ps` or `top` to see the process state).
>
> 3) if I want to compare execution speed of different versions of my
> program (original code vs code with some of the scratch files
> removed), which time should I compare?
If you are checking your own code, compare the user-cpu-cycles.
If you are checking different system calls, compare the
system-cpu-cycles.
Generally you can say that if you compare the same process with
different system load, the user-cpu cycles might vary a little, the
system-cpu might varry a little more but the real-time will varry a lot.
Patrick
The program I was talking about is actually a nonlinear finite element
program. It is mostly written in Fortran77, making big usage of
temporary files to pass data from one part of the program to another
(mainly two files: 1) one for storing the elemental stiffness matrixes
and 2) one for passing element data from one iteration to another). I
am trying to speed the whole thing up, so I replaced the file 2) by
dynamically allocated arrays.
These are my results of the time command: (old=original code; new=my
code)
old: user=115.48 / sys=59.29 / real=469.67
new: user=64.45 / sys=45.29 / real=290.00
As the new version has a lot less disk access, I can explain the
diminution of real time (which was, of course, the goal of all this).
Corné gives a clue for sys time: it includes buffer handling etc., so
if I use less temp files, this time goes down.
But I have absolutely no idea why user time goes down like that (gain
of about 45%). Can anyone explain?
Pat
Corné Beerse <cbe...@hiscom.nl> wrote in message news:<3dc0faa2$0$225$4d4e...@read.news.nl.uu.net>...
Michel OLAGNON
>Thanks for all your answers, things are beginning to look clearer..
>
>The program I was talking about is actually a nonlinear finite element
>program. It is mostly written in Fortran77, making big usage of
>temporary files to pass data from one part of the program to another
>(mainly two files: 1) one for storing the elemental stiffness matrixes
>and 2) one for passing element data from one iteration to another). I
>am trying to speed the whole thing up, so I replaced the file 2) by
>dynamically allocated arrays.
>
>These are my results of the time command: (old=original code; new=my
>code)
>
>old: user=115.48 / sys=59.29 / real=469.67
>new: user=64.45 / sys=45.29 / real=290.00
>
>As the new version has a lot less disk access, I can explain the
>diminution of real time (which was, of course, the goal of all this).
>Corné gives a clue for sys time: it includes buffer handling etc., so
>if I use less temp files, this time goes down.
>
>But I have absolutely no idea why user time goes down like that (gain
>of about 45%). Can anyone explain?
>
How were your WRITEs and READs ? Formatting data, looping in
arrays to send them to disk or fill them in, accessing memory
not in a sequential way can use a lot of CPU.
Michel
--
Michel OLAGNON email : Michel....@ifremer.fr
http://www.ifremer.fr/metocean/group/michel/michel_olagnon.htm
http://www.fortran-2000.com/
Dr Ivan D. Reid
wrote in <f7a75888.02110...@posting.google.com>:
> Thanks for all your answers, things are beginning to look clearer..
> The program I was talking about is actually a nonlinear finite element
> program. It is mostly written in Fortran77, making big usage of
> temporary files to pass data from one part of the program to another
> (mainly two files: 1) one for storing the elemental stiffness matrixes
> and 2) one for passing element data from one iteration to another). I
> am trying to speed the whole thing up, so I replaced the file 2) by
> dynamically allocated arrays.
> These are my results of the time command: (old=original code; new=my
> code)
> old: user=115.48 / sys=59.29 / real=469.67
> new: user=64.45 / sys=45.29 / real=290.00
> As the new version has a lot less disk access, I can explain the
> diminution of real time (which was, of course, the goal of all this).
> Corné gives a clue for sys time: it includes buffer handling etc., so
> if I use less temp files, this time goes down.
> But I have absolutely no idea why user time goes down like that (gain
> of about 45%). Can anyone explain?
Were your temporary files written in ASCII rather than binary? It
could be the time taken to do the output formatting -- I was looking at
Uncle Al's crystallography problem at the weekend, using the simplified
programme Jon posted, and none of my tricks could get the compilation time
to change significantly; then I took out the line outputting three DP
coordinates (a couple of hundred thousand times) and processing time
dropped from 28 seconds to less than 0.1![1] This may have been due to g77
optimising the loops away, but outputting just one of the three gave a 9.5
second run-time.
[1] D'oh!
--
Ivan Reid, Electronic & Computer Eng., Brunel Uni. Ivan...@brunel.ac.uk
KotPT -- "for stupidity above and beyond the call of duty".
Patrick
> How were your WRITEs and READs ? Formatting data, looping in
> arrays to send them to disk or fill them in, accessing memory
> not in a sequential way can use a lot of CPU.
>
> Michel
Each elements write and reads a lot of variables, arrays as well as
single variables. Each array is accessed in a sequentiel way (like
write(unit) ARRAY, or WRITE(UNIT) ((ARRAY(I,J),I=1,MI),J=1,MJ), so I
don't think the arrays take a lot of time.
Could it take a lot of cpu time just to "jump" from one variable to
another (in each element, there are over 100 variables to be read and
then written again)?
P
Michel OLAGNON
>
>> How were your WRITEs and READs ? Formatting data, looping in
>> arrays to send them to disk or fill them in, accessing memory
>> not in a sequential way can use a lot of CPU.
>>
>> Michel
>
>Each elements write and reads a lot of variables, arrays as well as
>single variables. Each array is accessed in a sequentiel way (like
>write(unit) ARRAY,
Fast, yes.
>or WRITE(UNIT) ((ARRAY(I,J),I=1,MI),J=1,MJ)
Not so fast at all with many systems, not fast at all on any system
if (/ MI, MJ /) /= UBOUND(ARRAY).
> , so I don't think the arrays take a lot of time.
>
>Could it take a lot of cpu time just to "jump" from one variable to
>another (in each element, there are over 100 variables to be read and
>then written again)?
>
>P
Michel