Misc #15014
closedthread.c: use rb_hrtime_scalar for high-resolution time operations
Description
thread.c: use rb_hrtime_t scalar for high-resolution time operations
Relying on "struct timespec" was too annoying API-wise and
used more stack space. "double" was a bit wacky w.r.t rounding
in the past, so now we'll switch to using a 64-bit type.
Unsigned 64-bit integer is able to give us over nearly 585
years of range with nanoseconds. This range is good enough
for the Linux kernel internal time representation, so it
ought to be good enough for us.
This reduces the stack usage of functions while GVL is held
(and thus subject to marking) on x86-64 Linux (with ppoll):
rb_wait_for_single_fd 120 => 104
do_select 120 => 88
I plan on using this for Timeout-in-VM [Feature #14859] and
auto-fiber [Feature #13618].
Files
Updated by MSP-Greg (Greg L) over 6 years ago
@normalperson (Eric Wong) Eric,
At r64493, ruby-loco built successfully using the abiove patch, Thanks, Greg
Updated by normalperson (Eric Wong) over 6 years ago
Greg.mpls@gmail.com wrote:
At r64493, ruby-loco built successfully using the abiove patch, Thanks, Greg
Thanks! I don't know when I'll commit this, yet.
Updated by ko1 (Koichi Sasada) about 6 years ago
Just a comment.
API references (a list of provided functions with a comment) at the beginning of the hrtime.h will help us.
Updated by normalperson (Eric Wong) about 6 years ago
ko1@atdot.net wrote:
Just a comment.
API references (a list of provided functions with a comment) at the beginning of the hrtime.h will help us.
OK, updated:
https://80x24.org/spew/20180823103503.29516-1-e@80x24.org/raw
(Should have Thread::Coro (auto-fiber) update using that, soon,
so the benefit will become more apparent, but personal crap
keeps getting in the way of hacking :<)
Updated by normalperson (Eric Wong) about 6 years ago
- Status changed from Open to Closed
Applied in changeset trunk|r64533.
thread.c: use rb_hrtime_t scalar for high-resolution time operations
Relying on "struct timespec" was too annoying API-wise and
used more stack space. "double" was a bit wacky w.r.t rounding
in the past, so now we'll switch to using a 64-bit type.
Unsigned 64-bit integer is able to give us over nearly 585
years of range with nanoseconds. This range is good enough
for the Linux kernel internal time representation, so it
ought to be good enough for us.
This reduces the stack usage of functions while GVL is held
(and thus subject to marking) on x86-64 Linux (with ppoll):
rb_wait_for_single_fd 120 => 104
do_select 120 => 88
[ruby-core:88582] [Misc #15014]
Updated by ko1 (Koichi Sasada) about 6 years ago
Thanks!
- Hi-res monotonic clock. It is currently nsec resolution, which has over 500 years of range (unsigned).
uint64?
MY_RUBY_BUILD_MAY_TIME_TRAVEL
what is this?
Updated by normalperson (Eric Wong) about 6 years ago
ko1@atdot.net wrote:
Thanks!
- Hi-res monotonic clock. It is currently nsec resolution, which has over 500 years of range (unsigned).
uint64?
You're welcome. Yep. Maybe some small systems can benefit with
usec/msec resolution and uint32_t, though.
However...
MY_RUBY_BUILD_MAY_TIME_TRAVEL
what is this?
A joke; at least as far as we know it is a joke :>
Updated by ko1 (Koichi Sasada) about 6 years ago
On 2018/08/27 16:16, Eric Wong wrote:
Yep. Maybe some small systems can benefit with
usec/msec resolution and uint32_t, though.
My comment is, if it assumes uint64_t, it is worth to write it
explicitly (I verified this years with 2^64/ (1000 * 1000 * 1000 * 60 * 60 * 24 * 365)
on google, but it will help for readers).
MY_RUBY_BUILD_MAY_TIME_TRAVEL
what is this?
A joke; at least as far as we know it is a joke :>
I'm not sure why uint64_t doesn't solve time machine problem and
uint128_t solves it. Any RFC arguing it? (time machines should not leap
1.0790283e+22 years)?
Beside joking, I misunderstand that some systems can change the machine
time (time machine may means it) which affect monotonic time, and I
could not understand why uint128 can solve such system issue.
--
// SASADA Koichi at atdot dot net
Updated by normalperson (Eric Wong) about 6 years ago
Koichi Sasada ko1@atdot.net wrote:
On 2018/08/27 16:16, Eric Wong wrote:
Yep. Maybe some small systems can benefit with
usec/msec resolution and uint32_t, though.My comment is, if it assumes uint64_t, it is worth to write it explicitly (I
verified this years with2^64/ (1000 * 1000 * 1000 * 60 * 60 * 24 * 365)
on google, but it will help for readers).
OK, I made r64554
MY_RUBY_BUILD_MAY_TIME_TRAVEL
what is this?
A joke; at least as far as we know it is a joke :>
I'm not sure why uint64_t doesn't solve time machine problem and uint128_t
solves it. Any RFC arguing it? (time machines should not leap 1.0790283e+22
years)?
It delays the onset of the problem. 585 years well within the
known range of human history; but 1.0790283e+22 years is much
farther away (probably beyond lifespan of the universe).
On the other hand, I don't know how a monotonic clock behaves
when a computer travels through time :>
Beside joking, I misunderstand that some systems can change the machine time
(time machine may means it) which affect monotonic time, and I could not
understand why uint128 can solve such system issue.
Right, if monotonic time goes out of uint64_t range, things will
break. Maybe int128 can hide the problem. But I don't think
it's something we need to care about, though (OS would be
broken, I think).
Updated by ko1 (Koichi Sasada) about 6 years ago
On 2018/08/27 18:17, Eric Wong wrote:
A joke; at least as far as we know it is a joke :>
I'm not sure why uint64_t doesn't solve time machine problem and uint128_t
solves it. Any RFC arguing it? (time machines should not leap 1.0790283e+22
years)?It delays the onset of the problem. 585 years well within the
known range of human history; but 1.0790283e+22 years is much
farther away (probably beyond lifespan of the universe).
We need to a time machine to confirm it :p
(but ruby doesn't support it...
any other language runtime support it? :p)
Beside joking, I misunderstand that some systems can change the machine time
(time machine may means it) which affect monotonic time, and I could not
understand why uint128 can solve such system issue.
--
// SASADA Koichi at atdot dot net