Prev: ANN: Seed7 Release 2010-03-07
Next: pthread_mutex/ptheread_spinlocks & shared memory
From: Sumer Cip on 7 Mar 2010 22:30
Hi all,

I am developing a profiler, and in my tests, it seems most of time
spent in the profiler is the gettimeofday() function. I have also used
clock_gettime() function and gives same results. Is there any way to
optimize the below piece of code more? Maybe another syscall I am
missing or anything?

static long long
tickcount(void)
{
struct timeval tv;
long long rc;
#ifdef GETTIMEOFDAY_NO_TZ
gettimeofday(&tv);
#else
gettimeofday(&tv, (struct timezone *)NULL);
#endif
rc = tv.tv_sec;
rc = rc * 1000000 + tv.tv_usec;
return rc;
}

Thanks,
From: Ian Collins on 7 Mar 2010 22:44
Sumer Cip wrote:
> Hi all,
>
> I am developing a profiler, and in my tests, it seems most of time
> spent in the profiler is the gettimeofday() function. I have also used
> clock_gettime() function and gives same results. Is there any way to
> optimize the below piece of code more? Maybe another syscall I am
> missing or anything?
>
> static long long
> tickcount(void)
> {
> struct timeval tv;
> long long rc;
> #ifdef GETTIMEOFDAY_NO_TZ
> gettimeofday(&tv);
> #else
> gettimeofday(&tv, (struct timezone *)NULL);
> #endif
> rc = tv.tv_sec;
> rc = rc * 1000000 + tv.tv_usec;
> return rc;
> }

It should be fast. On Solaris, gettimeofday() is a fairly thin wrapper
for gethrtime(). So if your system supports it (I think it is a POSIX
RT function), use that.

--
Ian Collins
From: David Schwartz on 8 Mar 2010 00:52
On Mar 7, 7:30 pm, Sumer Cip <sum...(a)gmail.com> wrote:

> I am developing a profiler, and in my tests, it seems most of time
> spent in the profiler is the gettimeofday() function. I have also used
> clock_gettime() function and gives same results. Is there any way to
> optimize the below piece of code more? Maybe another syscall I am
> missing or anything?

On x86 systems with one TSC or known synchronized TSCs, you can use
'rdtsc'. I think pretty much you just need to accept that profiling
will be invasive.

DS
From: Sumer Cip on 8 Mar 2010 08:55
Interestingly tried 'rdtsc' just to see what is happening and it gives
the same results. It is a simple 3 lines of ASM call. Well, is there a
way to tradeoff between accuracy, for example If I say only second
precision enough, then is there a faster function? Why I am pushing
this is because profiler's %95 runtime overhead is because of this
call?

On 8 Mart, 07:52, David Schwartz <dav...(a)webmaster.com> wrote:
> On Mar 7, 7:30 pm, Sumer Cip <sum...(a)gmail.com> wrote:
>
> > I am developing a profiler, and in my tests, it seems most of time
> > spent in the profiler is the gettimeofday() function. I have also used
> > clock_gettime() function and gives same results. Is there any way to
> > optimize the below piece of code more? Maybe another syscall I am
> > missing or anything?
>
> On x86 systems with one TSC or known synchronized TSCs, you can use
> 'rdtsc'. I think pretty much you just need to accept that profiling
> will be invasive.
>
> DS

From: Chris Friesen on 8 Mar 2010 10:19
On 03/08/2010 07:55 AM, Sumer Cip wrote:
> Interestingly tried 'rdtsc' just to see what is happening and it gives
> the same results. It is a simple 3 lines of ASM call. Well, is there a
> way to tradeoff between accuracy, for example If I say only second
> precision enough, then is there a faster function? Why I am pushing
> this is because profiler's %95 runtime overhead is because of this
> call?

Have you looked at the assembly to make sure that your instrumentation
is giving you what you expect? "rdtsc" should be pretty fast.

If it's still not fast enough, then you can't do exact profiling and you
need to go to statistical methods. A simple version is to program the
RTC to interrupt you at some interval (preferably not a multiple or
divisor of the system clock) and then use the value of the instruction
pointer when you were interrupted to bump some statistics.

Chris
 |  Next  |  Last
Pages: 1 2 3 4 5 6
Prev: ANN: Seed7 Release 2010-03-07
Next: pthread_mutex/ptheread_spinlocks & shared memory