[erlang-questions] hrtime/0, Was: now/0 resolution

[Serge Aleynikov]

Oh, I also forgot to state that exposing clock_gettime() via a driver 
and using erlang:port_call/3 takes around 75us on the same machine as 
below, so a BIF would definitely be a better choice in this regard.

Serge Aleynikov wrote:
> Here's a little test I ran on Linux (i386, 3GHz) to measure timer 
> performance:
> 
> clock resolution: 0.010 s
> gettimeofday() resolution: 4 us
> gettimeofday() duration = 10 us
> hrtime() resolution: 120 ns
> hrtime() 1 iteration cost = 130 ns
> clock_gettime() resolution = 461 ns
> clock_gettime() 1 iteration cost = 117 ns
> 
> 
> I also got a few private responses supporting community interest in an 
> HR timer BIFs.  To address Mikael's question, I also think that both 
> actual/virtual time BIFs could be useful.
> 
> Serge
> 
> Ulf Wiger (TN/EAB) wrote:
>> Raimo Niskanen wrote:
>>>
>>> New question:
>>>
>>> Serge apparently want a new BIF e.g hrtime/0 that would return
>>> the best high resolution time the implementation knows on the
>>> running OS. The precision would be OS dependant, but the best
>>> known to the emulator, and it would be the fastest way to get it.
>>> This BIF could also be suitable for getting high resolution
>>> CPU time as well as wallclock time.
>>>
>>> How much interest for such a BIF is there from the community?
>>>
>>> This would perhaps better be asked for in an EEP, but
>>> this is a first poll.
>>
>> We are very interested, and should even have this as a
>> formal requirement somewhere (maybe it got lost along
>> the way...)
>>
>> What I've asked for in the past is a time value that has
>> _at least_ millisecond precision, but I will gladly
>> settle for the best precision available. (:
>>
>> BR,
>> Ulf W
>>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions