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.

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.

Ian

-- 
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.

Reply via email to