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

With some changes to your code I got the difference down to two microseconds:

#!/usr/bin/perl
use Time::HiRes qw(gettimeofday);

my ($secs1,$sec2,$micro1,$micro2);
#discard once
gettimeofday();
($secs1, $micro1) = gettimeofday();
($secs2, $micro2) = gettimeofday();
print "$secs1$micro1\n";
print "$secs2$micro2\n";

__OUTPUT__
1133355471176848
1133355471176850
[download]

This is on a dual-2.8GHz Xeon, so I suspect you'll have trouble getting it to display identical values on a "normal" current system.

As for whether it's theoretically possible, I am pretty sure it'd be possible on SMP machines.

Update: after thinking about this some more, I'm pretty sure this is also possible on uniprocessor machines if you're running an operating system with a preemptible kernel.

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

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

Replies are listed 'Best First'.
Re^2: OT How fast a cpu to overwhelm Time::HiRes by Anonymous Monk on Nov 30, 2005 at 15:27 UTC
More than theoretical. I got it down to reliable 1 microsecond and the occasional 0 microseconds on a dual Xeon 3.06 with HT. `#!/usr/bin/perl use Time::HiRes qw(gettimeofday); my @timings = (0,0,0,0); #discard once @timings = (gettimeofday(), gettimeofday()); @timings = (gettimeofday(), gettimeofday()); print "$timings[0]$timings[1]\n"; print "$timings[2]$timings[3]\n"; __OUTPUT__ 1133364015468783 1133364015468783` [download] So the answer to the OP is yes - you can get identical timestamps out of Time::HiRes with a sufficiently fast system.	[reply] [d/l]
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
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]