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

Replies are listed 'Best First'.
Re^3: OT How fast a cpu to overwhelm Time::HiRes by snowhare (Friar) on Nov 30, 2005 at 16:18 UTC
Correction - that was a SINGLE 3.06 Xeon with HT.	[reply]
Re^3: OT How fast a cpu to overwhelm Time::HiRes by BrowserUk (Patriarch) on Nov 30, 2005 at 18:01 UTC
Sorry, but if this is true, and I don't doubt you are seeing what you say you are seeing, then something is being cached somewhere. 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]
Re^4: OT How fast a cpu to overwhelm Time::HiRes by snowhare (Friar) on Nov 30, 2005 at 22:35 UTC
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.)	[reply] [d/l]
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]
Re^4: OT How fast a cpu to overwhelm Time::HiRes by tirwhan (Abbot) on Dec 01, 2005 at 00:54 UTC
I don't think so, I can see the same results with his code, and if I run it through strace I get `gettimeofday({1133398137, 976963}, NULL) = 0 read(3, "", 4096) = 0 close(3) = 0 gettimeofday({1133398137, 977352}, NULL) = 0 gettimeofday({1133398137, 977383}, NULL) = 0 gettimeofday({1133398137, 977417}, NULL) = 0 gettimeofday({1133398137, 977441}, NULL) = 0 write(1, "1133398137977417\n113339813797744"..., 341133398137977417 1133398137977441) = 34` [download] So you can see that all the gettimeofday system calls are actually taking place and the values are being printed out. It's possible of course that this is an artifact of the tracing, and the value is cached otherwise, but that doesn't seem too likely. Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan	[reply] [d/l]