https://bugs.ruby-lang.org/https://bugs.ruby-lang.org/favicon.ico?17113305112013-07-20T04:52:18ZRuby Issue Tracking SystemRuby master - Feature #8658: Process.clock_gettimehttps://bugs.ruby-lang.org/issues/8658?journal_id=405872013-07-20T04:52:18Zkosaki (Motohiro KOSAKI)kosaki.motohiro@gmail.com
<ul></ul><p>First, Process.times() returns user time and system time and they are process specific. But Process::CLOCK_MONOTONIC is not per-process time.</p>
<p>Second, Linux's CLOCK_MONOTONIC_RAW has the same behavior BSD's CLOCK_MONOTONIC. And, an application which measures a performance need to use CLOCK_MONOTONIC_RAW for avoiding ntp confusing. Then, we should do 1) exporse CLOCK_MONOTONIC_RAW or 2) Process.clock_gettime(Process::CLOCK_MONOTONIC) uses CLOCK_MONOTONIC_RAW internally.</p>
<p>Third, using float is a good ruby convention. If we need to use inter (for precision and performance?), the method should have a precision explanation, likes get_time_nanosecond. I mean, ruby interpreter can't warn nor detect following mistake.</p>
<p>a = foo # this is usec<br>
b = bar # this is nsec<br>
c = a + b</p>
<p>then, we should warn by method name verbosely. IMHO.</p> Ruby master - Feature #8658: Process.clock_gettimehttps://bugs.ruby-lang.org/issues/8658?journal_id=405902013-07-20T19:39:19Zakr (Akira Tanaka)akr@fsij.org
<ul><li><strong>File</strong> <a href="/attachments/3800">clock_gettime-2.patch</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/3800/clock_gettime-2.patch">clock_gettime-2.patch</a> added</li></ul><p>kosaki (Motohiro KOSAKI) wrote:</p>
<blockquote>
<p>First, Process.times() returns user time and system time and they are process specific. But Process::CLOCK_MONOTONIC is not per-process time.</p>
</blockquote>
<p>Yes. Users can choose any clock with Process.clock_gettime unlike other proposals (<a class="issue tracker-2 status-1 priority-4 priority-default" title="Feature: Add Time#elapsed to return nanoseconds since creation (Open)" href="https://bugs.ruby-lang.org/issues/8640">#8640</a>, <a class="issue tracker-2 status-7 priority-4 priority-default closed" title="Feature: introduce Time.current_timestamp (Feedback)" href="https://bugs.ruby-lang.org/issues/8096">#8096</a>).</p>
<p>It seems many people use CLOCK_REALTIME to measure a time interval, though.</p>
<blockquote>
<p>Second, Linux's CLOCK_MONOTONIC_RAW has the same behavior BSD's CLOCK_MONOTONIC. And, an application which measures a performance need to use CLOCK_MONOTONIC_RAW for avoiding ntp confusing. Then, we should do 1) exporse CLOCK_MONOTONIC_RAW or 2) Process.clock_gettime(Process::CLOCK_MONOTONIC) uses CLOCK_MONOTONIC_RAW internally.</p>
</blockquote>
<p>OS specific CLOCK_* constants can be defined.<br>
Since Process.clock_gettime is a primitive, exchange clk_id is not a good idea.</p>
<blockquote>
<p>Third, using float is a good ruby convention. If we need to use inter (for precision and performance?), the method should have a precision explanation, likes get_time_nanosecond. I mean, ruby interpreter can't warn nor detect following mistake.</p>
<p>a = foo # this is usec<br>
b = bar # this is nsec<br>
c = a + b</p>
<p>then, we should warn by method name verbosely. IMHO.</p>
</blockquote>
<p>Hm. It is acceptable as far as the exact result (number of nanoseconds) can be obtained.</p>
<p>After thinking while, I find Process.clock_gettime(clk_id, unit).<br>
unit is an optional argument and :nanoseconds specifies the nanoseconds.<br>
This can help performance on ILP33 because :microseconds with CLOCK_PROCESS_CPUTIME_ID<br>
will not use Bignum until 1073 seconds after process start up.</p>
<p>I updated the patch.</p> Ruby master - Feature #8658: Process.clock_gettimehttps://bugs.ruby-lang.org/issues/8658?journal_id=405952013-07-21T14:53:11Zduerst (Martin Dürst)duerst@it.aoyama.ac.jp
<ul></ul><p>Hello Akira,</p>
<p>On 2013/07/19 21:32, akr (Akira Tanaka) wrote:</p>
<blockquote>
<p>On LP64 systems, Fixnum can represent 2<strong>62-1.<br>
So (2</strong>62-1)/(365.25<em>24</em>60<em>60</em>1e9)=146.1 years are representable<br>
without object allocation.</p>
<p>On ILP32 and LLP64 systems, Fixnum can represent 2<strong>30-1.<br>
So (2</strong>30-1)/1e9=1.07 seconds are representable<br>
without object allocation.<br>
This means Bignum allocations are mostly required except<br>
the origin is very recent.</p>
</blockquote>
<p>Don't your calculations ignore the fact that Fixnums are signed? Or do<br>
you have a way to use negative amounts of nanoseconds, too?</p>
<p>Regards, Martin.</p> Ruby master - Feature #8658: Process.clock_gettimehttps://bugs.ruby-lang.org/issues/8658?journal_id=405972013-07-21T16:59:13Zakr (Akira Tanaka)akr@fsij.org
<ul></ul><p>2013/7/21 "Martin J. Dürst" <a href="mailto:duerst@it.aoyama.ac.jp" class="email">duerst@it.aoyama.ac.jp</a>:</p>
<blockquote>
<p>On 2013/07/19 21:32, akr (Akira Tanaka) wrote:</p>
<blockquote>
<p>On LP64 systems, Fixnum can represent 2<strong>62-1.<br>
So (2</strong>62-1)/(365.25<em>24</em>60<em>60</em>1e9)=146.1 years are representable<br>
without object allocation.</p>
<p>On ILP32 and LLP64 systems, Fixnum can represent 2<strong>30-1.<br>
So (2</strong>30-1)/1e9=1.07 seconds are representable<br>
without object allocation.<br>
This means Bignum allocations are mostly required except<br>
the origin is very recent.</p>
</blockquote>
<p>Don't your calculations ignore the fact that Fixnums are signed? Or do you<br>
have a way to use negative amounts of nanoseconds, too?</p>
</blockquote>
<p>% ./ruby -ve 'p (2<strong>62-1).class, (2</strong>62).class'<br>
ruby 2.1.0dev (2013-07-21 trunk 42095) [x86_64-linux]<br>
Fixnum<br>
Bignum</p>
<p>% ./ruby -ve 'p (2<strong>30-1).class, (2</strong>30).class'<br>
ruby 2.1.0dev (2013-07-21 trunk 42095) [i686-linux]<br>
Fixnum<br>
Bignum</p>
<a name="Whats-the-problem"></a>
<h2 >What's the problem?<a href="#Whats-the-problem" class="wiki-anchor">¶</a></h2>
<p>Tanaka Akira</p> Ruby master - Feature #8658: Process.clock_gettimehttps://bugs.ruby-lang.org/issues/8658?journal_id=405982013-07-21T19:15:37ZEregon (Benoit Daloze)
<ul></ul><p>While I appreciate Ruby is not always taking the lowest common denominator for functionality (fork, etc),<br>
we need a counterpart for Windows and OS X at least.</p>
<p><a href="https://github.com/copiousfreetime/hitimes" class="external">https://github.com/copiousfreetime/hitimes</a> does it pretty nicely and I would really enjoy seeing the functionality to measure a precise interval in core.</p>
<p>We should have a unified method for clock_gettime(), mach_absolute_time() and QueryPerformanceCounter().<br>
Actually, I think it would be better to have an API allowing to have the time difference directly in seconds (higher level and the concern for allocating is no more relevant, any unit can be used internally).</p>
<p>And this feature is not always compatible with the timestamp (given they are monotonic clocks), so I think there should be two separate methods.</p>
<p>naruse gave a very useful link in <a class="issue tracker-2 status-7 priority-4 priority-default closed" title="Feature: introduce Time.current_timestamp (Feedback)" href="https://bugs.ruby-lang.org/issues/8096">#8096</a>, <a href="http://www.python.org/dev/peps/pep-0418/" class="external">http://www.python.org/dev/peps/pep-0418/</a> .<br>
I do not wish for a so large API, but I think we should have the timestamp functionality like time.time()<br>
and a precise performance counter like time.perf_counter().</p>
<p>I would be fine having the clock_id as a parameter for supporting platforms if it proves really useful.</p> Ruby master - Feature #8658: Process.clock_gettimehttps://bugs.ruby-lang.org/issues/8658?journal_id=406242013-07-24T00:23:11Zakr (Akira Tanaka)akr@fsij.org
<ul></ul><p>2013/7/21 Eregon (Benoit Daloze) <a href="mailto:redmine@ruby-lang.org" class="email">redmine@ruby-lang.org</a>:</p>
<blockquote>
<p>Issue <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: Process.clock_gettime (Closed)" href="https://bugs.ruby-lang.org/issues/8658">#8658</a> has been updated by Eregon (Benoit Daloze).</p>
<p>While I appreciate Ruby is not always taking the lowest common denominator for functionality (fork, etc),<br>
we need a counterpart for Windows and OS X at least.</p>
</blockquote>
<p>Users of such OSs can contribute an emulation function for clock_gettime.</p>
<blockquote>
<p>naruse gave a very useful link in <a class="issue tracker-2 status-7 priority-4 priority-default closed" title="Feature: introduce Time.current_timestamp (Feedback)" href="https://bugs.ruby-lang.org/issues/8096">#8096</a>, <a href="http://www.python.org/dev/peps/pep-0418/" class="external">http://www.python.org/dev/peps/pep-0418/</a> .<br>
I do not wish for a so large API, but I think we should have the timestamp functionality like time.time()<br>
and a precise performance counter like time.perf_counter().</p>
</blockquote>
<p>PEP 0418 mentions that python provide clock_gettime as time.clock_gettime.<br>
PEP 0418 doesn't mean providing clock_gettime itself is bad idea.</p>
<h2>Higer level methods may be useful but what I intend in this issue is a<br>
low level primitive.</h2>
<p>Tanaka Akira</p> Ruby master - Feature #8658: Process.clock_gettimehttps://bugs.ruby-lang.org/issues/8658?journal_id=406252013-07-24T01:22:23ZEregon (Benoit Daloze)
<ul></ul><p>akr (Akira Tanaka) wrote:</p>
<blockquote>
<blockquote>
<p>While I appreciate Ruby is not always taking the lowest common denominator for functionality (fork, etc),<br>
we need a counterpart for Windows and OS X at least.</p>
</blockquote>
<p>Users of such OSs can contribute an emulation function for clock_gettime.</p>
</blockquote>
<p>A very poor one as mapping to Linux/UNIX constants would just confuse people.<br>
I do not think the UNIX API clock_gettime() for this is the most suitable,<br>
it does not abstract the functionality and the name/usage is not very ruby-like.</p>
<p>I think FFI would be a good way if someone need direct access to that low-level C function (except for accessing the constants, that would not be handy).</p>
<blockquote>
<blockquote>
<p>naruse gave a very useful link in <a class="issue tracker-2 status-7 priority-4 priority-default closed" title="Feature: introduce Time.current_timestamp (Feedback)" href="https://bugs.ruby-lang.org/issues/8096">#8096</a>, <a href="http://www.python.org/dev/peps/pep-0418/" class="external">http://www.python.org/dev/peps/pep-0418/</a> .<br>
I do not wish for a so large API, but I think we should have the timestamp functionality like time.time()<br>
and a precise performance counter like time.perf_counter().</p>
</blockquote>
<p>PEP 0418 mentions that python provide clock_gettime as time.clock_gettime.<br>
PEP 0418 doesn't mean providing clock_gettime itself is bad idea.</p>
</blockquote>
<p>I believe providing a method which is only available in a quite restricted set of platforms is to be avoided.<br>
In Python it is simply not defined on non-supporting platforms.</p>
<blockquote>
<p>Higer level methods may be useful but what I intend in this issue is a<br>
low level primitive.</p>
</blockquote>
<p>To which use-cases other than benchmarking do you think?</p>
<p>I want Ruby to propose a nice and precise way to benchmark code <em>not</em> requiring the user to know about every detail of available clocks/timers under every platform.</p> Ruby master - Feature #8658: Process.clock_gettimehttps://bugs.ruby-lang.org/issues/8658?journal_id=406272013-07-24T03:14:37Zjonforums (Jon Forums)
<ul></ul><p>Eregon (Benoit Daloze) wrote:</p>
<blockquote>
<p>akr (Akira Tanaka) wrote:</p>
<blockquote>
<blockquote>
<p>While I appreciate Ruby is not always taking the lowest common denominator for functionality (fork, etc),<br>
we need a counterpart for Windows and OS X at least.</p>
</blockquote>
<p>Users of such OSs can contribute an emulation function for clock_gettime.</p>
</blockquote>
<p>A very poor one as mapping to Linux/UNIX constants would just confuse people.<br>
I do not think the UNIX API clock_gettime() for this is the most suitable,<br>
it does not abstract the functionality and the name/usage is not very ruby-like.</p>
<p>I think FFI would be a good way if someone need direct access to that low-level C function (except for accessing the constants, that would not be handy).</p>
<blockquote>
<blockquote>
<p>naruse gave a very useful link in <a class="issue tracker-2 status-7 priority-4 priority-default closed" title="Feature: introduce Time.current_timestamp (Feedback)" href="https://bugs.ruby-lang.org/issues/8096">#8096</a>, <a href="http://www.python.org/dev/peps/pep-0418/" class="external">http://www.python.org/dev/peps/pep-0418/</a> .<br>
I do not wish for a so large API, but I think we should have the timestamp functionality like time.time()<br>
and a precise performance counter like time.perf_counter().</p>
</blockquote>
<p>PEP 0418 mentions that python provide clock_gettime as time.clock_gettime.<br>
PEP 0418 doesn't mean providing clock_gettime itself is bad idea.</p>
</blockquote>
<p>I believe providing a method which is only available in a quite restricted set of platforms is to be avoided.<br>
In Python it is simply not defined on non-supporting platforms.</p>
</blockquote>
<p>It's great to see a focus on cross-platform impl issues :)</p>
<p>Has anyone spelunked libuv's awesomeness for inspiration on a nice cross-platform implementation style?</p>
<a name="general-header-niceness"></a>
<h1 >general header niceness<a href="#general-header-niceness" class="wiki-anchor">¶</a></h1>
<p><a href="https://github.com/joyent/libuv/blob/master/include/uv.h#L62-L67" class="external">https://github.com/joyent/libuv/blob/master/include/uv.h#L62-L67</a><br>
<a href="https://github.com/joyent/libuv/blob/master/include/uv-unix.h" class="external">https://github.com/joyent/libuv/blob/master/include/uv-unix.h</a><br>
<a href="https://github.com/joyent/libuv/blob/master/include/uv-win.h" class="external">https://github.com/joyent/libuv/blob/master/include/uv-win.h</a></p>
<a name="common-timer-API"></a>
<h1 >common timer API<a href="#common-timer-API" class="wiki-anchor">¶</a></h1>
<p><a href="https://github.com/joyent/libuv/blob/master/include/uv.h#L1873-L1881" class="external">https://github.com/joyent/libuv/blob/master/include/uv.h#L1873-L1881</a></p>
<a name="internal-platform-specific-header-timer-niceness"></a>
<h1 >internal platform specific header timer niceness<a href="#internal-platform-specific-header-timer-niceness" class="wiki-anchor">¶</a></h1>
<p><a href="https://github.com/joyent/libuv/blob/master/src/unix/internal.h#L180-L181" class="external">https://github.com/joyent/libuv/blob/master/src/unix/internal.h#L180-L181</a></p>
<a name="platform-specific-impl-niceness"></a>
<h1 >platform specific impl niceness<a href="#platform-specific-impl-niceness" class="wiki-anchor">¶</a></h1>
<p><a href="https://github.com/joyent/libuv/blob/master/src/win/util.c#L443-L465" class="external">https://github.com/joyent/libuv/blob/master/src/win/util.c#L443-L465</a><br>
<a href="https://github.com/joyent/libuv/blob/master/src/unix/core.c#L78-L80" class="external">https://github.com/joyent/libuv/blob/master/src/unix/core.c#L78-L80</a><br>
<a href="https://github.com/joyent/libuv/blob/master/src/unix/linux-core.c#L245-L249" class="external">https://github.com/joyent/libuv/blob/master/src/unix/linux-core.c#L245-L249</a></p> Ruby master - Feature #8658: Process.clock_gettimehttps://bugs.ruby-lang.org/issues/8658?journal_id=406282013-07-24T03:23:17Zkosaki (Motohiro KOSAKI)kosaki.motohiro@gmail.com
<ul></ul><p>(7/20/13 6:39 AM), akr (Akira Tanaka) wrote:</p>
<blockquote>
<p>Issue <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: Process.clock_gettime (Closed)" href="https://bugs.ruby-lang.org/issues/8658">#8658</a> has been updated by akr (Akira Tanaka).</p>
<p>File clock_gettime-2.patch added</p>
<p>kosaki (Motohiro KOSAKI) wrote:</p>
<blockquote>
<p>First, Process.times() returns user time and system time and they are process specific. But Process::CLOCK_MONOTONIC is not per-process time.</p>
</blockquote>
<p>Yes. Users can choose any clock with Process.clock_gettime unlike other proposals (<a class="issue tracker-2 status-1 priority-4 priority-default" title="Feature: Add Time#elapsed to return nanoseconds since creation (Open)" href="https://bugs.ruby-lang.org/issues/8640">#8640</a>, <a class="issue tracker-2 status-7 priority-4 priority-default closed" title="Feature: introduce Time.current_timestamp (Feedback)" href="https://bugs.ruby-lang.org/issues/8096">#8096</a>).</p>
<p>It seems many people use CLOCK_REALTIME to measure a time interval, though.</p>
</blockquote>
<p>So, Why do you choice Process.clock_gettime() instead of Time.clock_gettime()?</p>
<blockquote>
<blockquote>
<p>Second, Linux's CLOCK_MONOTONIC_RAW has the same behavior BSD's CLOCK_MONOTONIC. And, an application which measures a performance need to use CLOCK_MONOTONIC_RAW for avoiding ntp confusing. Then, we should do 1) exporse CLOCK_MONOTONIC_RAW or 2) Process.clock_gettime(Process::CLOCK_MONOTONIC) uses CLOCK_MONOTONIC_RAW internally.</p>
</blockquote>
<p>OS specific CLOCK_* constants can be defined.<br>
Since Process.clock_gettime is a primitive, exchange clk_id is not a good idea.</p>
</blockquote>
<p>Hm. OK.</p>
<blockquote>
<blockquote>
<p>Third, using float is a good ruby convention. If we need to use inter (for precision and performance?), the method should have a precision explanation, likes get_time_nanosecond. I mean, ruby interpreter can't warn nor detect following mistake.</p>
<p>a = foo # this is usec<br>
b = bar # this is nsec<br>
c = a + b</p>
<p>then, we should warn by method name verbosely. IMHO.</p>
</blockquote>
<p>Hm. It is acceptable as far as the exact result (number of nanoseconds) can be obtained.</p>
<p>After thinking while, I find Process.clock_gettime(clk_id, unit).<br>
unit is an optional argument and :nanoseconds specifies the nanoseconds.<br>
This can help performance on ILP33 because :microseconds with CLOCK_PROCESS_CPUTIME_ID<br>
will not use Bignum until 1073 seconds after process start up.</p>
<p>I updated the patch.</p>
</blockquote>
<p>An optional argument sound good idea.</p>
<p>thanks.</p> Ruby master - Feature #8658: Process.clock_gettimehttps://bugs.ruby-lang.org/issues/8658?journal_id=406302013-07-24T10:53:16Zakr (Akira Tanaka)akr@fsij.org
<ul></ul><p>2013/7/24 KOSAKI Motohiro <a href="mailto:kosaki.motohiro@gmail.com" class="email">kosaki.motohiro@gmail.com</a>:</p>
<blockquote>
<p>So, Why do you choice Process.clock_gettime() instead of<br>
Time.clock_gettime()?</p>
</blockquote>
<p>I don't like the result value of clock_gettime(CLOCK_REALTIME) because<br>
the value is interpreted differently between systems which use<br>
leapseconds and not.<br>
Time.now should be used instead.</p>
<p>The patch defines Process::CLOCK_REALTIME but it is just for consistency.<br>
I felt definining CLOCK_* constants except CLOCK_REALTIME is too inconsistent.</p>
<h2>The expected my main usecase would be CLOCK_PROCESS_CPUTIME_ID (or<br>
CLOCK_THREAD_CPUTIME_ID).<br>
For example, I use Process.times for measure Bignum speed but<br>
Process.times cannot measure under 10ms on my environment.<br>
Repeating target operation (as I do) improves precision but<br>
high resolution clocks can be used to obtain similar precision<br>
with less repeatation.</h2>
<p>Tanaka Akira</p> Ruby master - Feature #8658: Process.clock_gettimehttps://bugs.ruby-lang.org/issues/8658?journal_id=406702013-07-26T02:53:20Zkosaki (Motohiro KOSAKI)kosaki.motohiro@gmail.com
<ul></ul><p>(7/23/13 9:50 PM), Tanaka Akira wrote:</p>
<blockquote>
<p>2013/7/24 KOSAKI Motohiro <a href="mailto:kosaki.motohiro@gmail.com" class="email">kosaki.motohiro@gmail.com</a>:</p>
<blockquote>
<p>So, Why do you choice Process.clock_gettime() instead of<br>
Time.clock_gettime()?</p>
</blockquote>
<p>I don't like the result value of clock_gettime(CLOCK_REALTIME) because<br>
the value is interpreted differently between systems which use<br>
leapseconds and not.<br>
Time.now should be used instead.</p>
</blockquote>
<p>Hmm. OK.</p>
<blockquote>
<p>The patch defines Process::CLOCK_REALTIME but it is just for consistency.<br>
I felt definining CLOCK_* constants except CLOCK_REALTIME is too inconsistent.</p>
<p>The expected my main usecase would be CLOCK_PROCESS_CPUTIME_ID (or<br>
CLOCK_THREAD_CPUTIME_ID).<br>
For example, I use Process.times for measure Bignum speed but<br>
Process.times cannot measure under 10ms on my environment.<br>
Repeating target operation (as I do) improves precision but<br>
high resolution clocks can be used to obtain similar precision<br>
with less repeatation.</p>
</blockquote>
<p>Really? I don't think so because CLOCK_*_CPUTIME_ID have less precious than<br>
CLOCK_REALTIME. following "t" often show 0 on several OSs.</p>
<p>t0 = clock_gettime(CLOCK_THREAD_CPUTIME_ID)</p>
<a name="blah-blah-blah"></a>
<h1 >blah blah blah<a href="#blah-blah-blah" class="wiki-anchor">¶</a></h1>
<p>t1 = clock_gettime(CLOCK_THREAD_CPUTIME_ID)<br>
t = t1 - t0</p> Ruby master - Feature #8658: Process.clock_gettimehttps://bugs.ruby-lang.org/issues/8658?journal_id=406802013-07-26T12:53:10Zakr (Akira Tanaka)akr@fsij.org
<ul></ul><p>2013/7/24 Eregon (Benoit Daloze) <a href="mailto:redmine@ruby-lang.org" class="email">redmine@ruby-lang.org</a>:</p>
<blockquote>
<p>Issue <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: Process.clock_gettime (Closed)" href="https://bugs.ruby-lang.org/issues/8658">#8658</a> has been updated by Eregon (Benoit Daloze).</p>
<p>A very poor one as mapping to Linux/UNIX constants would just confuse people.<br>
I do not think the UNIX API clock_gettime() for this is the most suitable,<br>
it does not abstract the functionality and the name/usage is not very ruby-like.</p>
</blockquote>
<p>If constants defined by Unix is not suitable, original constants can be defined.</p>
<p>Ruby uses POSIX functions in general.<br>
So I think clock_gettime is very Ruby-ish (and I guess it is easier<br>
than original design<br>
to persuade matz).</p>
<blockquote>
<p>I think FFI would be a good way if someone need direct access to that low-level C function (except for accessing the constants, that would not be handy).</p>
</blockquote>
<p>How FFI can be used to call clock_gettime?<br>
I don't have experience with FFI.</p>
<blockquote>
<p>I believe providing a method which is only available in a quite restricted set of platforms is to be avoided.<br>
In Python it is simply not defined on non-supporting platforms.</p>
</blockquote>
<p>At least, CLOCK_REALTIME can be emulated on all platforms.<br>
Other clocks may be too, on some platforms.</p>
<p>Also, Ruby provides many platform dependent methods in Process.</p>
<blockquote>
<blockquote>
<p>Higer level methods may be useful but what I intend in this issue is a<br>
low level primitive.</p>
</blockquote>
<p>To which use-cases other than benchmarking do you think?</p>
</blockquote>
<p>I expect that I use CLOCK_PROCESS_CPUTIME_ID.</p>
<blockquote>
<p>I want Ruby to propose a nice and precise way to benchmark code <em>not</em> requiring the user to know about every detail of available clocks/timers under every platform.</p>
</blockquote>
<h2>It is good to have such high level methods but<br>
it doesn't conflict with low level methods.</h2>
<p>Tanaka Akira</p> Ruby master - Feature #8658: Process.clock_gettimehttps://bugs.ruby-lang.org/issues/8658?journal_id=406822013-07-26T12:59:09Zakr (Akira Tanaka)akr@fsij.org
<ul></ul><p>2013/7/26 KOSAKI Motohiro <a href="mailto:kosaki.motohiro@gmail.com" class="email">kosaki.motohiro@gmail.com</a>:</p>
<blockquote>
<p>Really? I don't think so because CLOCK_*_CPUTIME_ID have less precious than<br>
CLOCK_REALTIME. following "t" often show 0 on several OSs.</p>
<p>t0 = clock_gettime(CLOCK_THREAD_CPUTIME_ID)</p>
<a name="blah-blah-blah"></a>
<h1 >blah blah blah<a href="#blah-blah-blah" class="wiki-anchor">¶</a></h1>
<p>t1 = clock_gettime(CLOCK_THREAD_CPUTIME_ID)<br>
t = t1 - t0</p>
</blockquote>
<p>At least, my system can return 1ns unit.<br>
(It doesn't mean 1ns accuracy, of course.)</p>
<p>In following result, 4666 and 4667 are returned.</p>
<p>% ./ruby -ve '<br>
t1 = Process.clock_gettime(Process::CLOCK_PROCESS_CPUTIME_ID, :nanoseconds)<br>
while true<br>
t2 = Process.clock_gettime(Process::CLOCK_PROCESS_CPUTIME_ID, :nanoseconds)<br>
p t2-t1<br>
t1 = t2<br>
end<br>
'|head -20|sort -n<br>
ruby 2.1.0dev (2013-07-19 trunk 42049) [x86_64-linux]<br>
2861<br>
3984<br>
4154<br>
4189<br>
4222<br>
4267<br>
4452<br>
4567<br>
4620<br>
4666<br>
4667<br>
4771<br>
4870<br>
4920<br>
5296<br>
6155<br>
6428<br>
12690<br>
20290<br>
-e:5:in <code>p': Broken pipe (Errno::EPIPE) from -e:5:in </code>'<br>
% uname -mrsv<br>
Linux 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1 x86_64</p>
<a name="Other-platforms-can-behave-differently-though"></a>
<h2 >Other platforms can behave differently, though.<a href="#Other-platforms-can-behave-differently-though" class="wiki-anchor">¶</a></h2>
<p>Tanaka Akira</p> Ruby master - Feature #8658: Process.clock_gettimehttps://bugs.ruby-lang.org/issues/8658?journal_id=406962013-07-27T08:53:10Zakr (Akira Tanaka)akr@fsij.org
<ul></ul><p>2013/7/26 Tanaka Akira <a href="mailto:akr@fsij.org" class="email">akr@fsij.org</a>:</p>
<blockquote>
<p>2013/7/26 KOSAKI Motohiro <a href="mailto:kosaki.motohiro@gmail.com" class="email">kosaki.motohiro@gmail.com</a>:</p>
<blockquote>
<p>Really? I don't think so because CLOCK_*_CPUTIME_ID have less precious than<br>
CLOCK_REALTIME. following "t" often show 0 on several OSs.</p>
<p>t0 = clock_gettime(CLOCK_THREAD_CPUTIME_ID)</p>
<a name="blah-blah-blah"></a>
<h1 >blah blah blah<a href="#blah-blah-blah" class="wiki-anchor">¶</a></h1>
<p>t1 = clock_gettime(CLOCK_THREAD_CPUTIME_ID)<br>
t = t1 - t0</p>
</blockquote>
<p>At least, my system can return 1ns unit.<br>
(It doesn't mean 1ns accuracy, of course.)</p>
<p>In following result, 4666 and 4667 are returned.</p>
<p>% ./ruby -ve '<br>
t1 = Process.clock_gettime(Process::CLOCK_PROCESS_CPUTIME_ID, :nanoseconds)<br>
while true<br>
t2 = Process.clock_gettime(Process::CLOCK_PROCESS_CPUTIME_ID, :nanoseconds)<br>
p t2-t1<br>
t1 = t2<br>
end<br>
'|head -20|sort -n</p>
</blockquote>
<p>CLOCK_THREAD_CPUTIME_ID can return 1ns unit too.</p>
<p>% ./ruby -ve '<br>
t1 = Process.clock_gettime(Process::CLOCK_THREAD_CPUTIME_ID, :nanoseconds)<br>
while true<br>
t2 = Process.clock_gettime(Process::CLOCK_THREAD_CPUTIME_ID, :nanoseconds)<br>
p t2-t1<br>
t1 = t2<br>
end<br>
'|head -20|sort -n<br>
ruby 2.1.0dev (2013-07-19 trunk 42049) [x86_64-linux]<br>
2091<br>
3913<br>
3936<br>
3939<br>
3975<br>
3976<br>
3978<br>
4281<br>
4466<br>
4473<br>
4516<br>
4563<br>
4666<br>
4706<br>
-e:5:in <code>p'5604 6196 6342 13047 19388 : Broken pipe (Errno::EPIPE) from -e:5:in </code>'</p>
<p>(3975 and 3976 is returned.)</p>
<h2>CLOCK_THREAD_CPUTIME_ID may be preferable than CLOCK_PROCESS_CPUTIME_ID for<br>
measuring Bignum speed because it is purely single thread.</h2>
<p>Tanaka Akira</p> Ruby master - Feature #8658: Process.clock_gettimehttps://bugs.ruby-lang.org/issues/8658?journal_id=407962013-08-01T21:10:09Zakr (Akira Tanaka)akr@fsij.org
<ul><li><strong>File</strong> <a href="/attachments/3845">clock_gettime-3.patch</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/3845/clock_gettime-3.patch">clock_gettime-3.patch</a> added</li></ul><p>I updated the patch to emulate CLOCK_REALTIME using gettimeofday.</p> Ruby master - Feature #8658: Process.clock_gettimehttps://bugs.ruby-lang.org/issues/8658?journal_id=409012013-08-05T21:50:39Zakr (Akira Tanaka)akr@fsij.org
<ul><li><strong>File</strong> <a href="/attachments/3856">clock_gettime-4.patch</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/3856/clock_gettime-4.patch">clock_gettime-4.patch</a> added</li></ul><p>I updated the patch for Process.clock_gettime.<br>
The patch, clock_gettime-4.patch, supports gettimeofday() and time(),<br>
even when clock_gettime() is available.</p> Ruby master - Feature #8658: Process.clock_gettimehttps://bugs.ruby-lang.org/issues/8658?journal_id=410802013-08-11T12:13:19Zakr (Akira Tanaka)akr@fsij.org
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Closed</i></li></ul><p>I committed r42504 to implement Process.clock_gettime method.<br>
This is result of the meeting:<br>
<a href="https://bugs.ruby-lang.org/projects/ruby/wiki/DevelopersMeeting20130809" class="external">https://bugs.ruby-lang.org/projects/ruby/wiki/DevelopersMeeting20130809</a></p>
<p>This doesn't mean that high level API is rejected.<br>
Feel free to discuss it.</p> Ruby master - Feature #8658: Process.clock_gettimehttps://bugs.ruby-lang.org/issues/8658?journal_id=421752013-10-02T03:48:33Zheadius (Charles Nutter)headius@headius.com
<ul></ul><p>I missed the discussion on this, but here's the summary of JRuby/JVM case:</p>
<p>If monotonic clock is available at OS level, System.nanoTime is equivalent to clock_gettime(CLOCK_MONOTONIC). I suppose there may be some embedded systems or obscure platforms that don't have a monotonic clock, but otherwise I'm guessing this is going to be pretty universal across *nixes. The code in JDK is in <a href="http://hg.openjdk.java.net/jdk7/jdk7/hotspot/file/9b0ca45cd756/src/os/linux/vm/os_linux.cpp" class="external">http://hg.openjdk.java.net/jdk7/jdk7/hotspot/file/9b0ca45cd756/src/os/linux/vm/os_linux.cpp</a> at line 1453.</p>
<p>If monotonic clock is not available on *nix, JVM will fall back on gettimeofday transparently. I'm investigating whether it is possible for us to query this behavior.</p>
<p>System.currentTimeMillis is just a plain gettimeofday call, which in the Process::clock_gettime API is called GETTIMEOFDAY_BASED_CLOCK_REALTIME.</p>
<p>So JRuby will always be able to support GETTIMEOFDAY_BASED_CLOCK_REALTIME via System.currentTimeMillis, CLOCK_MONOTONIC when nanoTime is monotonic, and the other forms when we're able to make a native downcall. Initially, we will probably just support these two.</p>
<p>I HAVE A QUESTION, however... what about Windows? There's no mention at all in the rdoc about Windows support. I need to investigate what currentTimeMillis and nanoTime do on JVM on Windows.</p> Ruby master - Feature #8658: Process.clock_gettimehttps://bugs.ruby-lang.org/issues/8658?journal_id=421762013-10-02T04:02:12Zheadius (Charles Nutter)headius@headius.com
<ul></ul><p>JRuby issue for this feature: <a href="https://github.com/jruby/jruby/issues/1056" class="external">https://github.com/jruby/jruby/issues/1056</a></p>
<p>Windows information for JVM:</p>
<p>System.currentTimeMillis is always implemented using win32 GetSystemTimeAsFileTime function.</p>
<p><a href="http://msdn.microsoft.com/en-us/library/windows/desktop/ms724397(v=vs.85).aspx" class="external">http://msdn.microsoft.com/en-us/library/windows/desktop/ms724397(v=vs.85).aspx</a></p>
<p>System.nanoTime is implemented using QueryPerformanceCounter if available (Windows 2000 or higher), falling back on currentTimeMillis if it is not. This appears (by looking around in other articles) to be "rawtime", so perhaps equivalent to CLOCK_MONOTONIC_RAW? I think that would suffice for us to use it for CLOCK_MONOTONIC, but it's not very clear from available info.</p>
<p><a href="http://msdn.microsoft.com/en-us/library/windows/desktop/ms644904(v=vs.85).aspx" class="external">http://msdn.microsoft.com/en-us/library/windows/desktop/ms644904(v=vs.85).aspx</a></p>
<p>The latter article has a link in comments to a HOWTO on implementing a high-resolution timer on Windows. Bottom line is that some synchronization between the two functions is necessary, and it's pretty ugly.</p> Ruby master - Feature #8658: Process.clock_gettimehttps://bugs.ruby-lang.org/issues/8658?journal_id=421812013-10-02T05:13:26Zheadius (Charles Nutter)headius@headius.com
<ul></ul><p>Implementation in JRuby: <a href="https://github.com/jruby/jruby/commit/8c066241bd847b68d8d7255893edbad2d6c311d2" class="external">https://github.com/jruby/jruby/commit/8c066241bd847b68d8d7255893edbad2d6c311d2</a></p> Ruby master - Feature #8658: Process.clock_gettimehttps://bugs.ruby-lang.org/issues/8658?journal_id=421832013-10-02T07:29:11Zakr (Akira Tanaka)akr@fsij.org
<ul></ul><p>2013/10/2 headius (Charles Nutter) <a href="mailto:headius@headius.com" class="email">headius@headius.com</a>:</p>
<blockquote>
<p>I HAVE A QUESTION, however... what about Windows? There's no mention at all in the rdoc about Windows support. I need to investigate what currentTimeMillis and nanoTime do on JVM on Windows.</p>
</blockquote>
<a name="usa-san-implemented-clock_gettime-function-in-win32win32c"></a>
<h2 >usa-san implemented clock_gettime() function in win32/win32.c.<a href="#usa-san-implemented-clock_gettime-function-in-win32win32c" class="wiki-anchor">¶</a></h2>
<p>Tanaka Akira</p> Ruby master - Feature #8658: Process.clock_gettimehttps://bugs.ruby-lang.org/issues/8658?journal_id=421962013-10-02T13:29:57Znaruse (Yui NARUSE)naruse@airemix.jp
<ul></ul><p>akr (Akira Tanaka) wrote:</p>
<blockquote>
<p>2013/10/2 headius (Charles Nutter) <a href="mailto:headius@headius.com" class="email">headius@headius.com</a>:</p>
<blockquote>
<p>I HAVE A QUESTION, however... what about Windows? There's no mention at all in the rdoc about Windows support. I need to investigate what currentTimeMillis and nanoTime do on JVM on Windows.</p>
</blockquote>
<p>usa-san implemented clock_gettime() function in win32/win32.c.</p>
</blockquote>
<p>It is r42557 and other commits</p>