compute C program time
John
Do you have any good way to compute the functions' cpu time/elapse
time in C program?
Thanks.
Keith Thompson
> Do you have any good way to compute the functions' cpu time/elapse
> time in C program?
The clock() function tells you the elapsed CPU time. The time()
function gives you the real time (but its resolution is 1 second on
many systems).
There are other time functions on many systems, but they're not
defined by the C standard. Consult your system's documentation.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Richard Heathfield
clock() is the Bad Way, but might be your only shot. If you have access
to a profiler, however, that is the Good Way.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
John
> John wrote:
> > Dear all,
>
> > Do you have any good way to compute the functions' cpu time/elapse
> > time in C program?
>
> clock() is the Bad Way, but might be your only shot. If you have access
> to a profiler, however, that is the Good Way.
>
No profiler anyway, I just have std c functions.
then use clock function to compute the cpu time, and time function to
compute
the elapse time, right?
What is the profiler used to compute time in C program? do you know?
John Cui
remod
> What is the profiler used to compute time in C program? do you know?
If you're working on Linux you can use valgrind as a profile. I don't
know if it's available for other Unix versions but certainly is not for
Windows.
If you're using gcc, the profiler is gprof. You have to compile your
code with a set of specific switches. Have a look here:
http://www.cs.utah.edu/dept/old/texinfo/as/gprof_toc.html
If you're using another compiler, have a look at its manual. Talking
about freely available C compilers, I'm sure that lcc-win32 and
OpenWatcom both come with a profiler.
I suspect VisualStudio C++ Express doesn't but I have'nt checked.
Remo.D.
bartc
"Keith Thompson" <ks...@mib.org> wrote in message
news:lnfx6jv...@nuthaus.mib.org...
> John <cuiyou...@gmail.com> writes:
>> Do you have any good way to compute the functions' cpu time/elapse
>> time in C program?
>
> The clock() function tells you the elapsed CPU time.
Didn't you say the opposite a while back:
> "bartc" writes:
>> C's clock() function gives elapsed times in msec.
"Keith Thompson" <ks...@mib.org> wrote in message
news:lnpr5y7...@nuthaus.mib.org...
> No, it gives CPU time (not elapsed time), expressed as a value
> of type clock_t. To get the time in seconds, the result must be
> scaled by dividing by CLOCKS_PER_SEC.
?
--
Bartc
Richard
Try googling for a profiler for your compiler.
--
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
Richard
Richard
> John <cuiyou...@gmail.com> writes:
>> Do you have any good way to compute the functions' cpu time/elapse
>> time in C program?
>
> The clock() function tells you the elapsed CPU time. The time()
> function gives you the real time (but its resolution is 1 second on
> many systems).
>
> There are other time functions on many systems, but they're not
> defined by the C standard. Consult your system's documentation.
Better to give crap answers than real ones when OT eh? God you can be a
hindrance.
C and C usage is in topic here. You are fully aware of what profilers
exist for different platforms.
That said the OP was probably a troll...
Richard
In his haste to kill an "off topic" post Keith let his standards slip.
He was wrong anyway before since CPU time as value of clock_t is STILL
"time" and useful for analysis.
Richard Tobin
Richard <rgr...@gmail.com> wrote:
>If linux then gprof.
Last time I tried to use gprof I found it useless. It seems to sample
at a fixed rate, possibly 100Hz. This (or, as I remember it, 60Hz)
was useful 25 years ago, but with processors a thousand times faster
the granularity is far too coarse.
I would be delighted to learn that there's some way to fix this.
-- Richard
--
Please remember to mention me / in tapes you leave behind.
John
> remod <rdent...@gmail.com> writes:
> > John ha scritto:
>
> >> What is the profiler used to compute time in C program? do you know?
>
> > If you're working on Linux you can use valgrind as a profile. I don't
> > know if it's available for other Unix versions but certainly is not for
> > Windows.
>
> > If you're using gcc, the profiler is gprof. You have to compile your
> > code with a set of specific switches. Have a look here:
> >http://www.cs.utah.edu/dept/old/texinfo/as/gprof_toc.html
>
> > If you're using another compiler, have a look at its manual. Talking
> > about freely available C compilers, I'm sure that lcc-win32 and
> > OpenWatcom both come with a profiler.
>
> > I suspect VisualStudio C++ Express doesn't but I have'nt checked.
>
> > Remo.D.
>
> If linux then gprof.
>
I used cygwin with gcc on windows to code.
I used gprof, but I got stranger output.
the time of all functions are 0!
as below:
$ gprof.exe test_ORC.exe gmon.out
Flat profile:
Each sample counts as 0.01 seconds.
no time accumulated
% cumulative self self total
time seconds seconds calls Ts/call Ts/call name
0.00 0.00 0.00 78 0.00 0.00 ORCfilegetline
0.00 0.00 0.00 6 0.00 0.00 ORCstrncpy
0.00 0.00 0.00 6 0.00 0.00 ORCstrtrim
0.00 0.00 0.00 2 0.00 0.00 ORCfileopen
0.00 0.00 0.00 1 0.00 0.00 ORCcheckerror
0.00 0.00 0.00 1 0.00 0.00 ORCfilecreate
0.00 0.00 0.00 1 0.00 0.00 ORCfilegetinfo
0.00 0.00 0.00 1 0.00 0.00
ORCfilegetmaxline
0.00 0.00 0.00 1 0.00 0.00
ORCfilestatistics
Anyone can help me?
remod
> On Jan 6, 7:36 pm, Richard <rgrd...@gmail.com> wrote:
>
> I used gprof, but I got stranger output.
> the time of all functions are 0!
> as below:
>
> time seconds seconds calls Ts/call Ts/call name
> 0.00 0.00 0.00 78 0.00 0.00 ORCfilegetline
78 calls seems too few to collect significative measure. Try to collect
more sample (in the order of thousands or better millions call.
Ben Bacarisse
> John ha scritto:
>
>> What is the profiler used to compute time in C program? do you
>> know?
This is system specific and is best asked in a group the deals with
the system you are using.
> If you're working on Linux you can use valgrind as a profile. I don't
> know if it's available for other Unix versions but certainly is not
> for Windows.
>
> If you're using gcc, the profiler is gprof. You have to compile your
> code with a set of specific switches. Have a look here:
> http://www.cs.utah.edu/dept/old/texinfo/as/gprof_toc.html
There are lots of options beyond these and I have some comments I'd
make about this above if it were topical but I don't want this thread
to degenerate into debuggers/profilers for Linux/Windows/embedded
systems etc. The OP should ask about program timing in the right
group.
<snip>
--
Ben.
Ben Bacarisse
> remod <rden...@gmail.com> writes:
>> John ha scritto:
>>
>>> What is the profiler used to compute time in C program? do you know?
<snip>
> If linux then gprof.
If they asked in the right group they'd get better (or at least more
expansive) answers than that.
--
Ben.
John
After I read a very big file, the time still is 0.
$ gprof.exe test_ORCfile.exe gmon.out
Flat profile:
Each sample counts as 0.01 seconds.
no time accumulated
% cumulative self self total
time seconds seconds calls Ts/call Ts/call name
0.00 0.00 0.00 2462420 0.00 0.00 ORCfilegetline
0.00 0.00 0.00 4 0.00 0.00 ORCstrlen
0.00 0.00 0.00 4 0.00 0.00 ORCstrncpy
0.00 0.00 0.00 1 0.00 0.00 ORCcheckerror
0.00 0.00 0.00 1 0.00 0.00 ORCfilecreate
0.00 0.00 0.00 1 0.00 0.00 ORCfilefree
0.00 0.00 0.00 1 0.00 0.00 ORCfilegetinfo
0.00 0.00 0.00 1 0.00 0.00
ORCfilegetmaxline
0.00 0.00 0.00 1 0.00 0.00 ORCfileopen
0.00 0.00 0.00 1 0.00 0.00
ORCfilestatistics
$ gprof.exe -v
GNU gprof (GNU Binutils) 2.18.50.20080625
Based on BSD gprof, copyright 1983 Regents of the University of
California.
This program is free software. This program has absolutely no
warranty.
$ cygcheck.exe -c cygwin
Cygwin Package Information
Package Version Status
cygwin 1.7.1-1 OK
what is the reason??
John Cui
Keith Thompson
> "Keith Thompson" <ks...@mib.org> wrote in message
> news:lnfx6jv...@nuthaus.mib.org...
>> John <cuiyou...@gmail.com> writes:
>>> Do you have any good way to compute the functions' cpu time/elapse
>>> time in C program?
>>
>> The clock() function tells you the elapsed CPU time.
>
> Didn't you say the opposite a while back:
No.
>> "bartc" writes:
>>> C's clock() function gives elapsed times in msec.
>
> "Keith Thompson" <ks...@mib.org> wrote in message
> news:lnpr5y7...@nuthaus.mib.org...
>> No, it gives CPU time (not elapsed time), expressed as a value
>> of type clock_t. To get the time in seconds, the result must be
>> scaled by dividing by CLOCKS_PER_SEC.
>
> ?
By "elapsed time", I meant wall clock time. By "elapsed CPU time", I
meant CPU time.
remod
> On Jan 6, 10:14 pm, remod <rdent...@gmail.com> wrote:
>> John ha scritto:
>>> On Jan 6, 7:36 pm, Richard <rgrd...@gmail.com> wrote:
>> 78 calls seems too few to collect significative measure. Try to collect
>> more sample (in the order of thousands or better millions call.
> After I read a very big file, the time still is 0.
>
> % cumulative self self total
> time seconds seconds calls Ts/call Ts/call name
> 0.00 0.00 0.00 2462420 0.00 0.00 ORCfilegetline
Just to be sure, have you compiled and linked with the -pg option? 2M of
calls are definetely enough to get samples!!
Remo.D
John
Sure, I used -pg option. otherwise, I cannot get the gmon.out file.
Still have no solution....;(
Ben Bacarisse
Have you tried a more system-specific group? Maybe alt.comp.cygwin?
If not that, then a GNU group, perhaps.
--
Ben.
Phil Carmody
> "Keith Thompson" <ks...@mib.org> wrote in message
> news:lnfx6jv...@nuthaus.mib.org...
>> John <cuiyou...@gmail.com> writes:
>>> Do you have any good way to compute the functions' cpu time/elapse
>>> time in C program?
>>
>> The clock() function tells you the elapsed CPU time.
So CPU time not wall-clock time.
> Didn't you say the opposite a while back:
>
>> "bartc" writes:
>>> C's clock() function gives elapsed times in msec.
>
> "Keith Thompson" <ks...@mib.org> wrote in message
> news:lnpr5y7...@nuthaus.mib.org...
>> No, it gives CPU time
So CPU time not the wall-clock time.
>> (not elapsed time), expressed as a value
>> of type clock_t. To get the time in seconds, the result must be
>> scaled by dividing by CLOCKS_PER_SEC.
>
> ?
Look the same to me.
All time of any kind elapses, so that's not an important word
to focus on.
Phil
--
Any true emperor never needs to wear clothes. -- Devany on r.a.s.f1
Phil Carmody
> In article <hi1sjl$v01$3...@news.eternal-september.org>,
> Richard <rgr...@gmail.com> wrote:
>
>>If linux then gprof.
>
> Last time I tried to use gprof I found it useless. It seems to sample
> at a fixed rate, possibly 100Hz. This (or, as I remember it, 60Hz)
> was useful 25 years ago, but with processors a thousand times faster
> the granularity is far too coarse.
If your programs were running for several minutes in the past, and
are running for several minutes now, then it's precisely the same
level of granularity.
Just because processors are 1000x faster, doesn't mean you should
start trying to optimise things that take up 0.08% of the run time;
you should still be trying to optimise things that take 80% of the
run time.
> I would be delighted to learn that there's some way to fix this.
Run your program for longer. Bigger sample -> more information in
the data. Passive profiling is still all about statistics.
Phil Carmody
I don't consider sharing information about tools which C developers
may use to be off-topic.
For example, I don't use windows, I've not even seen a windows machine
for ages, and I rabidly detest anything to do with windows, but I think
that posts like "New version of MSVC now with C99 compatability available
for free download" are perfectly on-topic.
Behind the abstract language there's a huge hinterland of real-world
use of the language - without those tools the language may as well
not exist.
Ben Bacarisse
> Ben Bacarisse <ben.u...@bsb.me.uk> writes:
>> remod <rden...@gmail.com> writes:
>>
>>> John ha scritto:
>>>
>>>> What is the profiler used to compute time in C program? do you
>>>> know?
>>
>> This is system specific and is best asked in a group the deals with
>> the system you are using.
>>
>>> If you're working on Linux you can use valgrind as a profile. I don't
>>> know if it's available for other Unix versions but certainly is not
>>> for Windows.
>>>
>>> If you're using gcc, the profiler is gprof. You have to compile your
>>> code with a set of specific switches. Have a look here:
>>> http://www.cs.utah.edu/dept/old/texinfo/as/gprof_toc.html
>>
>> There are lots of options beyond these and I have some comments I'd
>> make about this above if it were topical but I don't want this thread
>> to degenerate into debuggers/profilers for Linux/Windows/embedded
>> systems etc. The OP should ask about program timing in the right
>> group.
>
> I don't consider sharing information about tools which C developers
> may use to be off-topic.
Neither do it, as it happens. That's why I didn't make any complaint
about the suggestions to use valgrind or gprof or whatever, but the
discussion has reached a stage where the next step relative merits of
various timing strategies under whatever system the OP is using. That
sort of thing is, I contend, better kicked of with a fresh thread
where experts about that sort of thing are likely to be found.
> For example, I don't use windows, I've not even seen a windows machine
> for ages, and I rabidly detest anything to do with windows, but I think
> that posts like "New version of MSVC now with C99 compatability available
> for free download" are perfectly on-topic.
Absolutely. I can't think of anyone who'd object to that.
<snip>
--
Ben.
Richard Tobin
Phil Carmody <thefatphi...@yahoo.co.uk> wrote:
>> Last time I tried to use gprof I found it useless. It seems to sample
>> at a fixed rate, possibly 100Hz. This (or, as I remember it, 60Hz)
>> was useful 25 years ago, but with processors a thousand times faster
>> the granularity is far too coarse.
>If your programs were running for several minutes in the past, and
>are running for several minutes now, then it's precisely the same
>level of granularity.
But fortunately this is not the case! The programs in question take
of the order of a few seconds to run, sometimes less.
It would be possible to modify the program to perform the same
computation many times, but that's a pain, especially if the you have
to, say, add code to free data that would not otherwise be freed. Why
isn't there just a knob to set the sample frequency?
Richard Heathfield
> In article <87pr5me...@kilospaz.fatphil.org>,
> Phil Carmody <thefatphi...@yahoo.co.uk> wrote:
<snip>
>> If your programs were running for several minutes in the past, and
>> are running for several minutes now, then it's precisely the same
>> level of granularity.
>
> But fortunately this is not the case! The programs in question take
> of the order of a few seconds to run, sometimes less.
In which case, why on earth are you worried about performance?
<snip>
Richard Tobin
Richard Heathfield <r...@see.sig.invalid> wrote:
>> But fortunately this is not the case! The programs in question take
>> of the order of a few seconds to run, sometimes less.
>In which case, why on earth are you worried about performance?
Because I run hundreds of such programs one after the other.
(They're actually XML analogues of sed, grep, and so on - programs
that may be short, but whose performance is important because they are
used repeatedly in more complicated scripts.)
Keith Thompson
> In article <zM6dna19retvr9vW...@bt.com>,
> Richard Heathfield <r...@see.sig.invalid> wrote:
>>> But fortunately this is not the case! The programs in question take
>>> of the order of a few seconds to run, sometimes less.
>
>>In which case, why on earth are you worried about performance?
>
> Because I run hundreds of such programs one after the other.
>
> (They're actually XML analogues of sed, grep, and so on - programs
> that may be short, but whose performance is important because they are
> used repeatedly in more complicated scripts.)
I wonder if you might improve performance by combining them into a
single executable, saving the overhead of program startup. For a
program that takes "a few seconds", it probably won't make much
difference, but for something that runs for a fraction of a second
it might be significant.
Ian Collins
Use a better tool; something like the SunStudio profiler should give you
the level of detail you want.
--
Ian Collins
Kaz Kylheku
> It would be possible to modify the program to perform the same
> computation many times, but that's a pain, especially if the you have
> to, say, add code to free data that would not otherwise be freed. Why
> isn't there just a knob to set the sample frequency?
Use the kernel-based profiler oprofile. It profiles the whole system
at once, kernel and user space.
Richard Tobin
Keith Thompson <ks...@mib.org> wrote:
>I wonder if you might improve performance by combining them into a
>single executable, saving the overhead of program startup.
Yes, certainly. That would save a lot more, since it wouldn't have to
read in and write out the data as XML. But these are general purpose
utilities that other people are going to combine in unpredictable
ways.
Keith Thompson
> In article <lnd41lt...@nuthaus.mib.org>,
> Keith Thompson <ks...@mib.org> wrote:
>>I wonder if you might improve performance by combining them into a
>>single executable, saving the overhead of program startup.
>
> Yes, certainly. That would save a lot more, since it wouldn't have to
> read in and write out the data as XML. But these are general purpose
> utilities that other people are going to combine in unpredictable
> ways.
I was thinking of having the combined program do exactly what the
individual programs do now, which would only save the overhead of
program startup, but if the "sub-programs" can save time by passing
data to each other internally rather than by parsing and generating
XML, that's even better.
Maybe the single monolithic program could define a scripting
interface, allowing users to perform multiple operations without
ever leaving the program. Of course an invocation of any of your
existing programs could be replaced by a trivial script that just
performs one operation, perhaps specified on the command line.
(As an added bonus, and to get back to the topic of this thread,
you could probably get better profiling information using a script
that specifies doing the same action, say, 100 times.)
I don't know enough about what you're doing to know whether this
makes any sense.
Seebs
> I was thinking of having the combined program do exactly what the
> individual programs do now, which would only save the overhead of
> program startup, but if the "sub-programs" can save time by passing
> data to each other internally rather than by parsing and generating
> XML, that's even better.
Yes.
> Maybe the single monolithic program could define a scripting
> interface, allowing users to perform multiple operations without
> ever leaving the program. Of course an invocation of any of your
> existing programs could be replaced by a trivial script that just
> performs one operation, perhaps specified on the command line.
... and I was about to say "this is the sort of thing that usually
calls for a domain-specific language".
-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Lorenzo Villari
Keith Thompson <ks...@mib.org> wrote:
>
> (As an added bonus, and to get back to the topic of this thread,
> you could probably get better profiling information using a script
> that specifies doing the same action, say, 100 times.)
>
Like this one?
Richard Tobin
Seebs <usenet...@seebs.net> wrote:
>> Maybe the single monolithic program could define a scripting
>> interface, allowing users to perform multiple operations without
>> ever leaving the program. Of course an invocation of any of your
>> existing programs could be replaced by a trivial script that just
>> performs one operation, perhaps specified on the command line.
>... and I was about to say "this is the sort of thing that usually
>calls for a domain-specific language".
One has recently been developed:
http://www.w3.org/XML/XProc/docs/langspec.html
However, that doesn't mean it's not useful to be able to use traditional
shell scripts, especially if there are bits of non-XML processing in
there too. So yes, I'm aware of other possibilities, but I would still
like to be able to profile and speed up my short-lived C programs!