Re^4: OT How fast a cpu to overwhelm Time::HiRes

I doubt it. Here are the results of several runs:

[snowhare]$ ./hires-time.pl
1133389582245150
1133389582245151
[snowhare]$ ./hires-time.pl
113338958348908
113338958348909
[snowhare]$ ./hires-time.pl
1133389583585585
1133389583585586
[snowhare]$ ./hires-time.pl
1133389584217773
1133389584217774
[snowhare]$ ./hires-time.pl
1133389584827558
1133389584827559
[snowhare]$ ./hires-time.pl
1133389585762938
1133389585762939
[snowhare]$ ./hires-time.pl
1133389586273604
1133389586273605
[snowhare]$ ./hires-time.pl
1133389586920152
1133389586920152
[snowhare]$ ./hires-time.pl
1133389587601760
1133389587601761
[download]

If it was simply being cached, I would expect it to always give me 0 microsecond results - instead I get it perhaps one time in eight (which makes sense since the machine is doing a number of other things as well so I don't expect 100% repeatability in the runs' timing).

Unless you can spot something in Time::HiRes itself that would cause caching, I am inclined to view the numbers as correct. Regardless, it shows that Time::HiRes can produce identical timestamps when pushed hard on a fast machine (in this case a Linux box running perl 5.6.2.)

Comment on Re^4: OT How fast a cpu to overwhelm Time::HiRes Download Code

Replies are listed 'Best First'.
Re^5: OT How fast a cpu to overwhelm Time::HiRes by BrowserUk (Patriarch) on Dec 01, 2005 at 00:23 UTC
Nope. Looking at the code in HiRes.xs, I see nothing that would be caching it. On the contrary, the fact that the `gettimeofday()` maps directly to the system api on your system means that the path from Perl to XS to OS and back is almost a straight one: `void gettimeofday() PREINIT: struct timeval Tp; PPCODE: int status; status = gettimeofday (&Tp, NULL); if (status == 0) { if (GIMME == G_ARRAY) { EXTEND(sp, 2); PUSHs(sv_2mortal(newSViv(Tp.tv_sec))); PUSHs(sv_2mortal(newSViv(Tp.tv_usec))); } else { EXTEND(sp, 1); PUSHs(sv_2mortal(newSVnv(Tp.tv_sec + (Tp.tv_usec / 10 +00000.0)))); } }` [download] That combined with your using 5.6.2, which doesn't need to lookup thread contexts, means that the overhead of the transitions is truely minimal. I have to sit corrected and chalk one up to linux here. Using Perl on a system which forms the core of it's built-ins architecture has distinct performance advantages. What triggered the caching thing in my mind was your making both calls to gettimeofday() within the same statement. I have a built in suspicion of this that I realise now is a hangover from using some time-related calls in C. On at least two C compilers I've used in the past, the compiler would do a subexpression elimination on a pair of identical calls in the same statement with the result that you the same value both times. I was bitten by this in a rather expensive way once. That is obviously not the case here, but old pain lives long in the memory. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal? "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^5: OT How fast a cpu to overwhelm Time::HiRes
by BrowserUk (Patriarch) on Dec 01, 2005 at 00:23 UTC

Nope. Looking at the code in HiRes.xs, I see nothing that would be caching it. On the contrary, the fact that the gettimeofday() maps directly to the system api on your system means that the path from Perl to XS to OS and back is almost a straight one:

void
gettimeofday()
        PREINIT:
        struct timeval Tp;
        PPCODE:
        int status;
        status = gettimeofday (&Tp, NULL);
        if (status == 0) {
             if (GIMME == G_ARRAY) {
                 EXTEND(sp, 2);
                 PUSHs(sv_2mortal(newSViv(Tp.tv_sec)));
                 PUSHs(sv_2mortal(newSViv(Tp.tv_usec)));
             } else {
                 EXTEND(sp, 1);
                 PUSHs(sv_2mortal(newSVnv(Tp.tv_sec + (Tp.tv_usec / 10
+00000.0))));
             }
        }
[download]

That combined with your using 5.6.2, which doesn't need to lookup thread contexts, means that the overhead of the transitions is truely minimal.

I have to sit corrected and chalk one up to linux here. Using Perl on a system which forms the core of it's built-ins architecture has distinct performance advantages.

What triggered the caching thing in my mind was your making both calls to gettimeofday() within the same statement. I have a built in suspicion of this that I realise now is a hangover from using some time-related calls in C. On at least two C compilers I've used in the past, the compiler would do a subexpression elimination on a pair of identical calls in the same statement with the result that you the same value both times. I was bitten by this in a rather expensive way once.

That is obviously not the case here, but old pain lives long in the memory.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

[reply]
[d/l]
[select]