On Thu, Mar 1, 2018 at 10:13 AM, Ian Lance Taylor <i...@golang.org> wrote:
> On Thu, Mar 1, 2018 at 8:56 AM, James Chacon <chacon.ja...@gmail.com> > wrote: > > > > I know the time package includes support for using the cycle timer on the > > machine (if available) to get high precision monotonic time measurements. > > > > But...calling time.Now() appears to have a lot of overhead. Measuring the > > delay between 2 consecutive calls gives me anywhere from 150ns to 900+ns > > depending on arch (linux and OS/X for these 2 examples). > > > > My problem is I'm writing an emulator for an 8 bit cpu and on certain > types > > of emulation I want it to run at original clock speeds (so 550ns clock > > cycles or so in this case). Just measuring time.Now() at the start of a > > cycle and then subtracting time.Now() at the end to sleep for remaining > > won't work if the overhead of the calls exceeds my cycle time like it's > > doing on OS/X. I'm assuming negligible enough overhead for time.Sleep(). > > > > I know for benchmarking we deal with this by aggregating a lot of samples > > and then dividing out. Is there a way to get the timer data much quicker? > > I'm assuming on OS/X it's ending up doing the syscall for gettimeofday (I > > recall an open bug somewhere) which is where the large jump comes from. > > > > Or should I just measure my average latency when initializing my emulator > > and use that as a baseline for determining how much to sleep? i.e. > > effectively a mini benchmark on startup to determine local machine > average > > run time and assume some slop? > > I don't think there is any way we could make time.Now run noticeably > faster on Darwin. It's not doing a system call of any sort. > > I'm reading time·now in the 1.9.2 sources and it clearly has a fallback path to invoking the gettimeofday call. I hadn't looked at 1.10 yet so I'll update and check my results there. > Your best bet, if you can assume you are running on amd64, is a tiny > bit of assembly code to execute the rdtsc instruction. rdtsc has its > problems, but it will give you fairly accurate cycle time when it's > not way way off. > > I may go with that. Thanks James -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
