faster gettimeofday?
in [Unix Programming]
|
From: Sumer Cip on 8 Mar 2010 10:51 Thanks Chris. We have worked previously on GWC NCGL:) You have been answering my silly questions there and now here:) World is a small place. On 8 Mart, 17:19, Chris Friesen <cbf...(a)mail.usask.ca> wrote: > 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
From: Ersek, Laszlo on 8 Mar 2010 11:12 In article <4B951582.2040300(a)mail.usask.ca>, Chris Friesen <cbf123(a)mail.usask.ca> writes: > 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. Fantastic! I was trying to suggest timer_create() [0] with SIGEV_SIGNAL and timer_settime() [1], but couldn't tell what the program should do in the signal handler. However, your suggestion should be implementable on platforms with Realtime Signals Extension [2] by setting SA_SIGINFO, because then the handler will be entered [3] as void func(int signo, siginfo_t *info, void *context); and "the third argument can be cast to a pointer to an object of type ucontext_t to refer to the receiving thread's context that was interrupted when the signal was delivered". ucontext_t has a member [4] ----v---- mcontext_t uc_mcontext A machine-specific representation of the saved context. ----^---- and somebody described in this group earlier that this member provides access to the saved instruction pointer on Linux or so. setitimer() [5] even says ----v---- ITIMER_PROF Decrements both in process virtual time and when the system is running on behalf of the process. It is designed to be used by interpreters in statistically profiling the execution of interpreted programs. Each time the ITIMER_PROF timer expires, the SIGPROF signal is delivered. ----^---- I guess a histogram could be made of the collected IP values, and IP values could be translated to source code locations via addr2line. Cheers, lacos [0] http://www.opengroup.org/onlinepubs/9699919799/functions/timer_create.html [1] http://www.opengroup.org/onlinepubs/9699919799/functions/timer_settime.html [2] http://www.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04_02 [3] http://www.opengroup.org/onlinepubs/9699919799/functions/sigaction.html [4] http://www.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html [5] http://www.opengroup.org/onlinepubs/9699919799/functions/setitimer.html
From: Måns Rullgård on 8 Mar 2010 11:38 lacos(a)ludens.elte.hu (Ersek, Laszlo) writes: > In article <4B951582.2040300(a)mail.usask.ca>, Chris Friesen <cbf123(a)mail.usask.ca> writes: >> 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. > > Fantastic! I was trying to suggest timer_create() [0] with SIGEV_SIGNAL > and timer_settime() [1], but couldn't tell what the program should do in > the signal handler. However, your suggestion should be implementable on > platforms with Realtime Signals Extension [2] by setting SA_SIGINFO, > because then the handler will be entered [3] as > > [...] > > I guess a histogram could be made of the collected IP values, and IP > values could be translated to source code locations via addr2line. If you have a Linux system, oprofile does all this and more without any instrumentation required, and with very low overhead. Solaris probably has something similar, though I don't know the name. -- M�ns Rullg�rd mans(a)mansr.com
From: Ersek, Laszlo on 8 Mar 2010 11:52 In article <yw1xbpey7opo.fsf(a)unicorn.mansr.com>, =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= <mans(a)mansr.com> writes: > lacos(a)ludens.elte.hu (Ersek, Laszlo) writes: > >> In article <4B951582.2040300(a)mail.usask.ca>, Chris Friesen <cbf123(a)mail.usask.ca> writes: >>> 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. >> >> Fantastic! I was trying to suggest timer_create() [0] with SIGEV_SIGNAL >> and timer_settime() [1], but couldn't tell what the program should do in >> the signal handler. However, your suggestion should be implementable on >> platforms with Realtime Signals Extension [2] by setting SA_SIGINFO, >> because then the handler will be entered [3] as >> >> [...] >> >> I guess a histogram could be made of the collected IP values, and IP >> values could be translated to source code locations via addr2line. > > If you have a Linux system, oprofile does all this and more without > any instrumentation required, and with very low overhead. > > Solaris probably has something similar, though I don't know the name. Thanks! However, In article <e785d1bf-4317-4b0d-9c1a-d2f973eb45b0(a)u9g2000yqb.googlegroups.com>, Sumer Cip <sumerc(a)gmail.com> writes: > I am developing a profiler Thus the OP might need to (re)implement what oprofile does. (In which case your advice translates to "dear OP, please look at the source of oprofile", of course.) (... The website in your sig (mansr.com) makes my browser's connect() return with -1/ECONNREFUSED.) Cheers, lacos
From: Rick Jones on 8 Mar 2010 14:00
Ian Collins <ian-news(a)hotmail.com> wrote: > 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. I like gethrtime() - works great for things like netperf time histograms. That Solaris gettimeofday() would be a wrapper around gethrtime() is interesting - the Solaris manpage for gethrtime() talks about how it is "not correlated in any way to the time of day" which naturally, is fine for delta time measurements, but it would seem that the "fairly thin wrapper" would have to do all those things a "normal" gettimeofday() call would so the result would indeed represent the time of day. rick jones -- Wisdom Teeth are impacted, people are affected by the effects of events. these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... |