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>
>> > I know the time package includes support for using the cycle timer on
>> > machine (if available) to get high precision monotonic time
>> > But...calling time.Now() appears to have a lot of overhead. Measuring
>> > 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
>> > 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
>> > and then dividing out. Is there a way to get the timer data much
>> > I'm assuming on OS/X it's ending up doing the syscall for gettimeofday
>> > recall an open bug somewhere) which is where the large jump comes from.
>> > Or should I just measure my average latency when initializing my
>> > and use that as a baseline for determining how much to sleep? i.e.
>> > effectively a mini benchmark on startup to determine local machine
>> > 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
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.