Comments for Fabulous Adventures In Coding

Comment on Benchmarking mistakes, part two by Jim Mischel

Jim Mischel — Wed, 22 May 2013 19:39:12 +0000

NTP updates won't make things more accurate unless the thing you're timing takes a really long time. The default polling interval for NTP is usually quite long. Windows default, for example, is 7 days. Even if you use "constant synchronization," updates aren't going to occur more than once per minute, and usually much longer than that. If NTP updates can change the clock, then there is some bit of uncertainty in your timings. Given two start/end timestamp pairs, you can't compare them reliably because one pair might include adjustments to the clock and the other doesn't. I can't reliably compare two measurements obtained by taking the difference of DateTime.UtcNow values because NTP updates or other changes to the system clock might have occurred. The advantage of using Stopwatch (the high frequency timer) is that even though it might be inaccurate, it's consistent. I know that its report of 100 milliseconds, for example, represents the same time period every time. It might be only 99.987 milliseconds, but it's *always* 99.987 milliseconds. I can reliably compare two Stopwatch values obtained from the same machine.

Comment on Benchmarking mistakes, part two by Gabe

Gabe — Wed, 22 May 2013 15:58:59 +0000

The real reason to use DateTime.UtcNow in a benchmark (vs. DateTime.Now) is that it doesn't have the thousands-of-cycles overhead of computing the timezone offset. The other thing to keep in mind is that, while Stopwatch is likely to be far more precise, DateTime is likely to be more accurate. In other words, if your computer's clock runs slow, the mechanism DateTime uses may kept accurate via NTP, while the Stopwatch mechanism won't be.

Comment on Quality assurance fail by Random832

Random832 — Wed, 22 May 2013 15:42:07 +0000

Change .commentlist { width: 120% } to 100%.
Change #content { margin-right: 34% } to 23%.
Change #content { width: 58.4% } to 70%.
Change #secondary { width: 18.8% } to 13%.

Comment on Benchmarking mistakes, part two by Simon Cooper

Simon Cooper — Wed, 22 May 2013 14:11:18 +0000

I would disagree that System.Diagnostics is well-named and not for production use; Process is essential for production code and firing off new processes, and has got nothing to do with diagnostics. Some things like Debug asserts and DebuggableAttribute are useful to put in production code when you're debugging an issue in it.

Comment on Benchmarking mistakes, part two by Crag Gidney

Crag Gidney — Wed, 22 May 2013 08:00:59 +0000

Interestingly, when a high frequency timer is now available, StopWatch falls back to DateTime.UtcNow.

That means, if you somehow found a machine without a high frequency timer, you could change the result of your benchmark by changing your system date as the benchmark ran. The operating system might also change the result if it syncs the current time over NTP while your benchmark runs.

Comment on What is lexical scoping? by defaultex

defaultex — Wed, 22 May 2013 07:11:47 +0000

Looks better than my own technique, which after 7 years of it's inception has finally been detected by virus scanners as malicious code. Probably a good thing everyone I ever demonstrated it too called it overly complicated and decided not to adopt it.

Comment on Quality assurance fail by defaultex

defaultex — Wed, 22 May 2013 07:05:24 +0000

That thing tells a story, though I doubt it's the real story. I imagine a machine plugs those into a mock socket, measures stress on the points inside the socket, and them flops them into a reject or accept bin accordingly. Such a machine would certainly require a person to check it from time to time to ensure the mock socket was still functioning as expected. That poor soul probably ordered the wrong thing for lunch and had to make an emergency stop by the bathroom during his normal inspection time.

Comment on Benchmarking mistakes, part two by Sébastien Lorion

Sébastien Lorion — Wed, 22 May 2013 03:52:19 +0000

A bit off-topic, but that article got me thinking about what is the best class to use when implementing an ID generation algorithm similar to what Instagram has done (http://instagram-engineering.tumblr.com/post/10853187575/sharding-ids-at-instagram). I coded a similar algorithm in .NET using DateTime.UtcNow and since a server ID and sequence is used in addition to a timestamp in the ID, I suspect the actual precision of DateTime matters less, but still, would you advise using another class in that case ?

Comment on What is lexical scoping? by Joker_vD

Joker_vD — Tue, 21 May 2013 23:34:43 +0000

If I remember correctly, LISP was intended to use lexical scoping, but due to the bug in the implementation, it got dynamic scoping, and then it became a tradition.

Still, nothing beats ALGOL-60's call-by-name, if you ask me.

Comment on What is lexical scoping? by Gabe

Gabe — Tue, 21 May 2013 22:27:41 +0000

Perl is another popular language that supports dynamic scoping, with its "local" keyword. It is not uncommon for a n00b to attempt to declare a local variable, only to find that they've declared a variable that is globally available until its declaring function returns. Presumably the name is just an accident of history, because "local" was introduced with version 2 in 1988. Back then it was as local as you could get in Perl. When lexical scoping was introduced with Perl 5 in 1994, the name "local" was already taken, so "my" was chosen as the keyword to declare what we now consider to be local variables.