OTP-18 os:timestamp 10 times slower on OSX compared to OTP-17

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

OTP-18 os:timestamp 10 times slower on OSX compared to OTP-17

Pavel Martynenko
Poor performance of os:timestamp and erlang:now on OSX compared to OTP-17.

Here is the comparison of 1M cycles.

On OSX Darwin Kernel Version 14.3.0 (hardware)

Eshell V6.4  (abort with ^G)
1>
erlang:now/0                 232390
os:timestamp/0               116950

Eshell V7.0  (abort with ^G)
1>
erlang:now/0                1416680
erlang:timestamp/0          1151160
erlang:monotonic_time/0     1129957
erlang:system_time/0        1137389
erlang:time_offset/0          50977
erlang:unique_integer/0       52861
t:-test/0-fun-0-/0          1214256
os:timestamp/0              1003910
os:system_time/0            1008520

And Linux 3.16.0-41-generic (virtualised on the same hardware as OSX)

Eshell V6.4.1  (abort with ^G)
1>
erlang:now/0                2400925
os:timestamp/0              2223445

Eshell V7.0  (abort with ^G)
1>
erlang:now/0                2919313
erlang:timestamp/0          2654415
erlang:monotonic_time/0     2412814
erlang:system_time/0        2478186
erlang:time_offset/0          43202
erlang:unique_integer/0       34817
t:-test/0-fun-0-/0          2594927
os:timestamp/0              2065593
os:system_time/0            2007291

Where
t:-test/0-fun-0-/0 
is
fun () -> {erlang:monotonic_time(), erlang:unique_integer([monotonic])} end.

--
Cheers,
Pavlo Martynenko

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: OTP-18 os:timestamp 10 times slower on OSX compared to OTP-17

Pavel Martynenko
Linux 2.6.26-2-686 (hardware)

Eshell V6.4  (abort with ^G)
1>
erlang:now/0                1012080
os:timestamp/0               779001

Eshell V7.0  (abort with ^G)
1>
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".

--
Cheers,
Pavlo Martynenko

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: OTP-18 os:timestamp 10 times slower on OSX compared to OTP-17

Rickard Green-2
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)
> 1>
> erlang:now/0                1012080
> os:timestamp/0               779001
>
> Eshell V7.0  (abort with ^G)
> 1>
> 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".
>
> --
> Cheers,
> 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
better).

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.


Regards,
Rickard
--
Rickard Green, Erlang/OTP, Ericsson AB
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions