

Time Goes On in Erlang - lelf
http://learnyousomeerlang.com/time

======
jlouis
One may wonder why all these changes in Erlang/OTP 18.0? The reason, as the
chapter by ferd states, is lock contention.

Often, when you enabled the `lcnt` subsystem to find lock conflicts in busy
systems, you would run into the timer wheel lock. Removing that improves
parallelism in the system considerably.

And once you decide to take a stab at the time API, why not solve other
problems around it as well, now you are working on fixing parts of it?

~~~
derefr
Given how long the Erlang VM has been around and how much it's touted as
having the best solutions to this-or-that concurrency problem, I never
(naïvely) would have suspected it to have any low-hanging global-interpreter-
lock type fruit.

I suspect that this is a common-enough sentiment that there are a lot of VM
optimization people (insofar as there exist a lot of VM optimization people)
who would have been interested in working on this problem even years ago, if
the halo effect didn't prevent them from realizing it was there. Certainly
some of the people working on removing locks from Python, Ruby, the JVM, etc.
would have been intrigued by hacking locks out of BEAM.

~~~
rdtsc
> I never (naïvely) would have suspected it to have any low-hanging global-
> interpreter-lock type fruit.

The solution is elegant, but that doesn't necessarily mean it was low hanging.
(Maybe it was for the authors, I can't speak for them).

Sometimes you can't extrapolate the amount of work out of the complexity of
final solution. The relationship is often inverse.

~~~
derefr
Well, not "low-hanging" meaning "easy to fix" so much as "low-hanging" meaning
"really obvious high-ROI thing to fix."

------
lostcolony
Awesome to see that ferd added the new time API stuff. I already read the API
docs, and the key takeaway at the bottom is the same as there (i.e., when to
use each of the new functions), but LYSE is easily the most popular Erlang
intro out there.

------
Luc
'A clock on a plane goes slower than a clock on the ground'.

It's the other way around actually. I always mix them up too. See e.g.
[https://en.wikipedia.org/wiki/Gravitational_time_dilation](https://en.wikipedia.org/wiki/Gravitational_time_dilation)

Imagine a mechanical clock battling gravity to get its hands to move. Voila,
instant mnemonic.

~~~
qbit
I think the author may have been referring to time dilation due to relative
motion of the clocks as opposed to gravity. In that case, to an observer on
the ground, the clock on the plane goes slower than a clock on the ground.

~~~
Luc
Yes, you're probably right. Now I'll need to figure out which effect has the
upper hand. Maybe later.

EDIT: Flying clocks around:
[https://en.wikipedia.org/wiki/Hafele%E2%80%93Keating_experim...](https://en.wikipedia.org/wiki/Hafele%E2%80%93Keating_experiment)
If compared to a clock remaining on earth, then it depends on the direction
the plane is flying which effect wins.

------
rudiger
Great stuff. I'd love to see the best parts of this series redone for Elixir.

------
amelius
Why doesn't the OS take care of this?

It seems like the prototypical task for the OS.

~~~
scott_karana
I agree. System clocks should be based off of "International Atomic Time",
TAI, which is also monotonic, and not subject to UTC's leap seconds, as UTC is
calculated as an offset of TAI.

~~~
rvirding
Yes, but the VM clock guaranteed more, every time you access the clock using
erlang:now() you would get a monotonically increasing value. Practical to be
sure, but not scalable.

~~~
scott_karana
How does TAI not also solve monotonically increasing values, and in a
standardized way to boot? That's a characteristic of it by definition, as I
tried to explain. :P

