On Thu, Mar 1, 2018 at 11:07 PM, James Chacon <chacon.ja...@gmail.com>

> 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.
Wow...Ok, updating to 1.10 made a *huge* difference here. On 1.9.2 Darwin
was showing an average of 811ns for back to back time.Now() calls. On 1.10
it's 11-13ns :) I haven't tested amd64 linux yet but I'll assume it's

At that amount I can just go back to calling time.Now() at the start/end
and sleeping for the difference modula some slop.


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