PRI_stime

PRI_stime

[Jan Beulich]

George, Dario,

it being mostly used in scheduler code, and me considering it quite a
bit easier to compare such big numbers when shown in hex I wonder:
Do you prefer this to stay PRId64, or would you accept it to be
changed to PRIx64 (allowing it to be used in a few other places)?

Thanks, Jan

Re: PRI_stime

[George Dunlap]

On Tue, Oct 20, 2015 at 7:26 AM, Jan Beulich <JBeulich@suse.com> wrote:
> George, Dario,
>
> it being mostly used in scheduler code, and me considering it quite a
> bit easier to compare such big numbers when shown in hex I wonder:
> Do you prefer this to stay PRId64, or would you accept it to be
> changed to PRIx64 (allowing it to be used in a few other places)?

Personally I've never taken the time to familiarize myself with the
magnitude of hex numbers vs decimal numbers; so in the case of time, I
could easily see that 10000000 nanoseconds is about 1ms; but I don't
have a good sense of how long 0x1000000 nanoseconds is.  The fact that
our times are based on base 10 instead of base 2 is I think as good an
argument as any for leaving it as a decimal.

But I wouldn't oppose the change if Dario (or others) thought x64 was
the way to go.

 -George

Re: PRI_stime

[Juergen Gross]

On 10/20/2015 10:10 AM, George Dunlap wrote:
> On Tue, Oct 20, 2015 at 7:26 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> George, Dario,
>>
>> it being mostly used in scheduler code, and me considering it quite a
>> bit easier to compare such big numbers when shown in hex I wonder:
>> Do you prefer this to stay PRId64, or would you accept it to be
>> changed to PRIx64 (allowing it to be used in a few other places)?
>
> Personally I've never taken the time to familiarize myself with the
> magnitude of hex numbers vs decimal numbers; so in the case of time, I
> could easily see that 10000000 nanoseconds is about 1ms; but I don't

A good example for doing it in hex. Less digits are less error prone.
Your example would translate to 10ms. :-)

> have a good sense of how long 0x1000000 nanoseconds is.  The fact that

0x100000 is about 1 million. This helps a lot to get an idea of the
magnitude.

> our times are based on base 10 instead of base 2 is I think as good an
> argument as any for leaving it as a decimal.
>
> But I wouldn't oppose the change if Dario (or others) thought x64 was
> the way to go.

+1 for hex.


Juergen

Re: PRI_stime

[Jan Beulich]

>>> On 20.10.15 at 10:10, <George.Dunlap@eu.citrix.com> wrote:
> On Tue, Oct 20, 2015 at 7:26 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> George, Dario,
>>
>> it being mostly used in scheduler code, and me considering it quite a
>> bit easier to compare such big numbers when shown in hex I wonder:
>> Do you prefer this to stay PRId64, or would you accept it to be
>> changed to PRIx64 (allowing it to be used in a few other places)?
> 
> Personally I've never taken the time to familiarize myself with the
> magnitude of hex numbers vs decimal numbers; so in the case of time, I
> could easily see that 10000000 nanoseconds is about 1ms; but I don't
> have a good sense of how long 0x1000000 nanoseconds is.  The fact that
> our times are based on base 10 instead of base 2 is I think as good an
> argument as any for leaving it as a decimal.

Well, as long as the number of seconds the value represents is small,
this indeed is a good argument for using dec. However, already
when we get into the hour range we're talking about 12-digit values
without any separators, and at least for me this means counting
from either end to find a place where to put a mental separator. So
if staying with dec, perhaps we should make these second based,
i.e. <ssss>.<nnnnnnnnn>?

Jan

Re: PRI_stime

[Andrew Cooper]

On 20/10/15 09:34, Jan Beulich wrote:
>>>> On 20.10.15 at 10:10, <George.Dunlap@eu.citrix.com> wrote:
>> On Tue, Oct 20, 2015 at 7:26 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>> George, Dario,
>>>
>>> it being mostly used in scheduler code, and me considering it quite a
>>> bit easier to compare such big numbers when shown in hex I wonder:
>>> Do you prefer this to stay PRId64, or would you accept it to be
>>> changed to PRIx64 (allowing it to be used in a few other places)?
>> Personally I've never taken the time to familiarize myself with the
>> magnitude of hex numbers vs decimal numbers; so in the case of time, I
>> could easily see that 10000000 nanoseconds is about 1ms; but I don't
>> have a good sense of how long 0x1000000 nanoseconds is.  The fact that
>> our times are based on base 10 instead of base 2 is I think as good an
>> argument as any for leaving it as a decimal.
> Well, as long as the number of seconds the value represents is small,
> this indeed is a good argument for using dec. However, already
> when we get into the hour range we're talking about 12-digit values
> without any separators, and at least for me this means counting
> from either end to find a place where to put a mental separator. So
> if staying with dec, perhaps we should make these second based,
> i.e. <ssss>.<nnnnnnnnn>?

Having a custom %p for this would be very useful.

As for the original hex vs dec question, I am really not fussed, so long
as we are consistent (which is not the case currently).

~Andrew

Re: PRI_stime

[Jan Beulich]

>>> On 20.10.15 at 11:46, <andrew.cooper3@citrix.com> wrote:
> On 20/10/15 09:34, Jan Beulich wrote:
>>>>> On 20.10.15 at 10:10, <George.Dunlap@eu.citrix.com> wrote:
>>> On Tue, Oct 20, 2015 at 7:26 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> George, Dario,
>>>>
>>>> it being mostly used in scheduler code, and me considering it quite a
>>>> bit easier to compare such big numbers when shown in hex I wonder:
>>>> Do you prefer this to stay PRId64, or would you accept it to be
>>>> changed to PRIx64 (allowing it to be used in a few other places)?
>>> Personally I've never taken the time to familiarize myself with the
>>> magnitude of hex numbers vs decimal numbers; so in the case of time, I
>>> could easily see that 10000000 nanoseconds is about 1ms; but I don't
>>> have a good sense of how long 0x1000000 nanoseconds is.  The fact that
>>> our times are based on base 10 instead of base 2 is I think as good an
>>> argument as any for leaving it as a decimal.
>> Well, as long as the number of seconds the value represents is small,
>> this indeed is a good argument for using dec. However, already
>> when we get into the hour range we're talking about 12-digit values
>> without any separators, and at least for me this means counting
>> from either end to find a place where to put a mental separator. So
>> if staying with dec, perhaps we should make these second based,
>> i.e. <ssss>.<nnnnnnnnn>?
> 
> Having a custom %p for this would be very useful.

Yes, that's hat I was considering if we want to stay with decimal.

Jan

Re: PRI_stime

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 1592 bytes --]

On Tue, 2015-10-20 at 02:34 -0600, Jan Beulich wrote:
> > > > On 20.10.15 at 10:10, <George.Dunlap@eu.citrix.com> wrote:

> > Personally I've never taken the time to familiarize myself with the
> > magnitude of hex numbers vs decimal numbers; so in the case of
> > time, I
> > could easily see that 10000000 nanoseconds is about 1ms; but I
> > don't
> > have a good sense of how long 0x1000000 nanoseconds is.  The fact
> > that
> > our times are based on base 10 instead of base 2 is I think as good
> > an
> > argument as any for leaving it as a decimal.
> 
Yep, for time, I personally prefer decimal too.

> Well, as long as the number of seconds the value represents is small,
> this indeed is a good argument for using dec. However, already
> when we get into the hour range we're talking about 12-digit values
> without any separators, and at least for me this means counting
> from either end to find a place where to put a mental separator. So
> if staying with dec, perhaps we should make these second based,
> i.e. <ssss>.<nnnnnnnnn>?
> 
This would be really useful, and I'd be fine with scheduling related
PRI_stime to look like this. I think I really like it, actually.

It's what we do already for console timestamps, in case "=boot" is
specified, isn't it?

Thanks and Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel