Plotting PDQ Output with R

One the nice things about PDQ-R (coming in release 5.0) is the ability to plot PDQ output directly in R. Here's a PDQ-R script, together with the corresponding graphical output, that I knocked up to show the effect on the throughput curve of adding more queueing delay stages (K), with everything else held constant.

Don Knuth on Open Source, Multicores and Literate Programming

Donald Knuth, the father of TeX and author of the long unfinished multi-volume set of books entitled "The Art of Computer Programming", sounds off in this interesting interview.

His comment on unit testing (or an overzealous reliance on it) seems a bit obscured here. I am certainly more inclined to concur with his other quote: "early optimization is the root of all evil," because unit testing tends to promote that bad strategy with respect to system performance. Some personal war stories describing exactly that will be delivered this week in my Guerrilla Boot Camp class.

However, do read and heed what he says about multicores and multithreaded programming. It should sound familiar. BTW, where he apparently says "Titanium", he means Itanium.

His riff on "literate programming" is a bit of a yawn for me because we had that capability at Xerox PARC, 25 years ago. Effectively, you wrote computer code (Mesa/Cedar in that case) using the same WYSIWYG editor that you used for writing standard, fully-formatted documentation. The compiler didn't care. This encouraged very readable commentary within programs. In fact, you often had to look twice to decide if you were looking at a static document or dynamic program source. As I understand it, Knuth's worthy objective is to have this capability available for other languages. The best example that I am aware of today, that comes closest to what we had at Xerox, is the Mathematica notebook. You can also use Mathematica Player to view any example Mathematica notebooks without purchasing the Mathematica product.

Board from the Back of the Bus (maybe not)

When boarding a tour bus, the driver often tells you to occupy seats at the back of the bus first. This protocol is assumed to be more efficient than filling seats from the front because people block the aisle while stowing their carry-on baggage and thereby impede the flow. So, back-filling is more efficient than front-filling but is it optimal? The same procedure is used by airlines that implement boarding by groups A, B, C, etc. Group A is usually seated at the rear of the aircraft. There are some variants with aircraft boarding (e.g., window seats before aisle seats) that also help to distribute the passenger weight more evenly. The question remains, however, is it optimal?

An astrophysicist recently decided to look into this question more carefully using Monte Carlo simulations and found some surprising results. He unexpectedly discovered that the common rear boarding procedure is actually the second worst procedure, since it is only slightly more efficient than boarding front-to-back! So surprised was he, that at first, he thought there was a bug in his code. Then it became apparent that there was something more subtle going on. MC sims showed that an optimal boarding method was for passengers to board 10 at a time in every other row, since loading luggage requires about two aisles of space. In this way, passengers are either stowing luggage or sitting in their seats, rather than waiting in the aisle, as they do in the other two protocols. Depending on the size of the aircraft, this boarding procedure produces a speed up of 5 to 10 times over the worst case. Of course, disembarking is still LIFO. :-)

I wonder if this result could have applications in the context of computer or network performance analysis and capacity planning?

ORACLE Scalability Oracles

For those of you concerned with ORACLE 10g performance, there are a couple of books by ORACLE oracles that you might find useful; especially with regard to ORACLE scalability