[erlang-questions] hrtime/0, Was: now/0 resolution
Erik Stenman
erik.stenman@REDACTED
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
>> erlang-questions@REDACTED
>> http://www.erlang.org/mailman/listinfo/erlang-questions
>
> --
>
> / Raimo Niskanen, Erlang/OTP, Ericsson AB
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>
More information about the erlang-questions
mailing list