Sad Clouds wrote:
> On Tue, 10 Aug 2010 10:53:23 -0400
> James Carlson <carls...@workingcode.com> wrote:
>
>> Sad Clouds wrote:
>>> uint64_t current_time;
>>> while(1)
>>> {
>>> get_network_data();
>>> current_time = update_current_time();
>>> ...
>>> use_current_time();
>>> }
>>>
>>> So in a tight loop, if update_current_time() calls clock_gettime()
>>> on every loop iteration, what would kill performance.
>> How much execution time does update_current_time() take when compared
>> to get_network_data()?
>>
>> You might also want to look into the SO_TIMESTAMP option.
>
> It's just an example. The longest time would be time spent in
> clock_gettime() call, but it only calls clock_gettime() at specified
> intervals, which could be every second, or every microsecond, it
> depends on how accurate the application wants the current time to be.
> At all other times, the function calls a few simple arithmetic
> instructions to adjust 64-bit counters, so it's negligible.
I'm afraid I don't follow the example. How is it that getting data from
the network (which involves at least a read() system call and data
copying) isn't several orders of magnitude slower than getting the
current time of day? How is it that clock_gettime() isn't completely
buried in the noise?
> The general idea is not to call clock_gettime() on every loop
> iteration, but instead let CPU adjust 64-bit counters until the
> specified time interval is detected. This way the function is "self
> clocking" and provides a good estimate of current system time in tight
> loops.
If speed were a serious concern, I'd use gethrtime() instead. But I
still don't see how it's really a concern.
--
James Carlson 42.703N 71.076W <carls...@workingcode.com>
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
