Re: OTP-18 os:timestamp 10 times slower on OSX compared to OTP-17
On Tue, Jul 7, 2015 at 2:48 PM, Pavel Martynenko <[hidden email]> wrote:
> Linux 2.6.26-2-686 (hardware)
> Eshell V6.4 (abort with ^G)
> erlang:now/0 1012080
> os:timestamp/0 779001
> Eshell V7.0 (abort with ^G)
> erlang:now/0 1865773
> erlang:timestamp/0 1856433
> erlang:monotonic_time/0 1840571
> erlang:system_time/0 1851965
> erlang:time_offset/0 50446
> erlang:unique_integer/0 44924
> t:-test/0-fun-0-/0 1866288
> os:timestamp/0 938257
> os:system_time/0 896746
> Looks better than on OSX. Still almost 2x times slower to "Determine Order
> of Events With Time of the Event" as described in "Time and Time Correction
> in Erlang".
> Pavlo Martynenko
> erlang-questions mailing list
> [hidden email] > http://erlang.org/mailman/listinfo/erlang-questions >
Looking at MacOSX first:
The biggest problem on MacOSX is the performance of clock_get_time().
The performance of os:timestamp() and os:system_time() can be improved
by reverting to use of gettimeofday() for OS system time at the
expense of worse accuracy, resolution and precision of both monotonic
time and system time.
This will however not help improving erlang:monotonic_time(),
erlang:system_time(), or erlang:now(). clock_get_time() is needed for
time correction of these, so unfortunately the only way to improve on
these is to revert back to not using time correction.
By reverting to gettimeofday() and disabling time correction you are
more or less back to the implementation used on MacOSX in OTP 17
regarding retrieval of time.
Regarding the Linux case:
On newer kernels (newer than 2.6.39) the clock id CLOCK_BOOTTIME is
used for monotonic time instead of CLOCK_MONOTONIC since OTP 18. This
since CLOCK_BOOTTIME also include the time the machine is in a
suspended state. CLOCK_BOOTTIME however proved to be much more
expensive, so we will revert back to using CLOCK_MONOTONIC.
Besides this we've also found a performance bug where unnecessary data
is copied when retrieving corrected monotonic time. This effects all
systems except Linux with multi time warp mode enabled (which performs
When reverting to CLOCK_MONOTONIC and fixing the unnecessary copying,
the difference shrinks a lot. There is however still a difference in a
sequential benchmark. This due to overhead computing the time
correction in such a way that it is possible to retrieve time in
parallel without contention (the multi time warp mode implementation
on Linux does not have to compute this correction which is why it
performs better). However, as soon as you get contention on the time
retrieval, OTP 17 falls behind.
We will soon release a patch where:
- the unnecessary copying has been removed
- default monotonic clock id on linux has changed to CLOCK_MONOTONIC
- you can force usage of gettimeofday() for OS system time when
building the system.