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

Erik Stenman <>
Wed Sep 12 10:23:18 CEST 2007


There is support in Hipe for accessing performance counters in the CPU.
These has been used to great advantage while benchmarking and finding  
bottlenecks in HiPE.
Take a look at
   erts/emulator/hipe/hipe_perfctr.c
Perhaps it is time to make them official...

/Erik

On 12 sep 2007, at 09.42, Raimo Niskanen wrote:

> So, to conclude this thread, there is no much better way today.
> Call trace may in some cases be more convenient but not
> much more efficient and has no better precision.
>
> 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.
>
>
>
> Came to think about it. The current suggestion for FFI
> (Forein Function Interface) could be used to call the OS
> high resolution time functions, but then you would have
> to know the right call on every OS, and I do not know
> how efficient that call interface would be.
>
>
>
> On Fri, Sep 07, 2007 at 07:23:34AM -0500, Serge Aleynikov wrote:
>> Since according to documentation consecutive executions of now/0 will
>> return different values (with microsecond precision) I have two  
>> questions:
>>
>> 1. Does it mean that inserting now/0 calls in code will slow down
>> execution to 1mks per execution?  If not, then performance of  
>> function
>> call measured using now/0 time stamping would be inaccurate.
>>
>> 2. Is it possible to measure execution time more accurately (with
>> nanosecond precision) using current Erlang distribution? (*)
>>
>> Serge
>>
>> (*) Since VM uses gettimeofday() to bump timer, it's limited by
>> getimeofday's precision.  Additionally each invocation of  
>> gettimeofday
>> takes about 15mks (OS dependent).  I believe that there's no code to
>> take advantage of a high resolution timer.  Such a timer can give
>> nanosecond precision, and presently the only way it can be  
>> implemented
>> is in a linked-in driver.  The only problem that calling functions
>> inside the driver with erlang:port_call/3 incurs some cost that  
>> would be
>> better to avoid if a bif (such as hrnow/0) was available.
>>
>> _______________________________________________
>> erlang-questions mailing list
>> 
>> http://www.erlang.org/mailman/listinfo/erlang-questions
>
> -- 
>
> / Raimo Niskanen, Erlang/OTP, Ericsson AB
> _______________________________________________
> erlang-questions mailing list
> 
> http://www.erlang.org/mailman/listinfo/erlang-questions
>




More information about the erlang-questions mailing list