From: KOSAKI Motohiro <kosaki.motohiro@...>
Date: 2013-07-26T02:46:41+09:00
Subject: [ruby-core:56179] Re: [ruby-trunk - Feature #8658] Process.clock_gettime

(7/23/13 9:50 PM), Tanaka Akira wrote:
> 2013/7/24 KOSAKI Motohiro <kosaki.motohiro@gmail.com>:
>
>> So, Why do you choice Process.clock_gettime() instead of
>> Time.clock_gettime()?
>
> I don't like the result value of clock_gettime(CLOCK_REALTIME) because
> the value is interpreted differently between systems which use
> leapseconds and not.
> Time.now should be used instead.

Hmm. OK.


> The patch defines Process::CLOCK_REALTIME but it is just for consistency.
> I felt definining CLOCK_* constants except CLOCK_REALTIME is too inconsistent.
>
> The expected my main usecase would be CLOCK_PROCESS_CPUTIME_ID (or
> CLOCK_THREAD_CPUTIME_ID).
> For example, I use Process.times for measure Bignum speed but
> Process.times cannot measure under 10ms on my environment.
> Repeating target operation (as I do) improves precision but
> high resolution clocks can be used to obtain similar precision
> with less repeatation.

Really? I don't think so because CLOCK_*_CPUTIME_ID have less precious than
CLOCK_REALTIME. following "t" often show 0 on several OSs.


t0 = clock_gettime(CLOCK_THREAD_CPUTIME_ID)
# blah blah blah
t1 = clock_gettime(CLOCK_THREAD_CPUTIME_ID)
t = t1 - t0