In a break with centuries of reticence, perhaps the most widely recognised distributor of festive spirit and products, Santa Claus, has revealed some details of the HPC underpinning his time-critical global operations.

Although on the face of it Claus’ business has almost a year to prepare for the annual Christmas mayhem, in reality it is often late November, or even into December before the customer requests start to pour in. This leaves only a few frantic weeks to organise sourcing, manufacture, packaging and delivery planning before a publicly-known hard distribution deadline. To make it more complicated, as we know, Claus runs an unusual customer ordering model — the customer does not place actual orders, rather the hopeful recipient passes a list of desired items, usually via their parents or the mail, into the system. Claus’ operation then evaluates the requests to decide on the actual order to be supplied. It is strongly rumoured, but never formally acknowledged, that a large part of this decision process involves an amazing surveillance operation that is carried out throughout the preceding year on hundreds of millions of children to determine if they have been well behaved — good enough to get presents.

To those of us in the HPC industry, it is readily apparent that a considerable HPC infrastructure must underpin this entire operation — from surveillance and behaviour analysis through order processing to source/design/manufacture and logistics.

Through a process that we can’t reveal, we managed to discuss this HPC aspect with Claus. Our first interest was of scale — where on the TOP500 would his facility rank? “Well, clearly I can’t go into specifics” said Claus, “but like many others recently we have been looking towards a performance milestone. Unfortunately, for a variety of reasons we were unable to put the exascale facility into service this year. I guess many of the reasons will be familiar to your readers — for example, consider the heat generated. Although we have obvious cooling advantages in our Arctic location, we potentially have a huge climate impact too, especially on the local ice sheets. In fact one of the reasons we were considering moving to exascale was to better quantify the climate impact of our operations — including the huge mileage on Christmas Eve. We even compute the effect of relative changes in weight distribution throughout the delivery, as the cargo load gets lighter but I get heavier from all the mince pies kindly left out for me.”

At that scale we were very interested to learn what kind of HPC systems Claus was running. “Well, again, I can’t name our suppliers, but we actually use a combination of kits for different tasks. Like others we have used commodity solutions where we can, but, at our scale, custom solutions really deliver value and much of what we have is designed in house by the elves.”

Claus also discussed the impact of the pace of change within HPC on his business. “It’s not that we are scared of change – our customer base grows exponentially each year with new arrivals, but the elder customers drop out, so the turnover is huge. Plus, although individual customers return for several years, their requirements evolve rapidly from year to year. The problem with the pace of change in HPC is that we need a very stable service during our most critical business phase. Thus, we need to deploy a reliable and stable solution. Further, given the scale, we need to start planning that deployment some time ahead — leading to the difficulties of predicting the future of HPC as experienced by many of your readers.”

Given the community discussion around programming and support for such large HPC systems, we wanted to see if we could learn anything from Claus on that front. “A few generations ago we really came up against the problems of programming for extreme scales. One part of our response was to get the computer to do the work for us. For example, a substantial share of the compute capacity is used to run intelligent performance collection programs and using advanced data mining on this, coupled with predictive data mining for the coming season’s orders, to provide input to parts of the application stack that self-tune and modify their own scalability behaviour. In fact, we are experimenting with using the computational power, together with intelligent monitoring, to enable the facility to predict its own probable needs for the coming year — upgrades in capacity, anticipated failure replacements, etc. –- and to automatically order those.”

We noted that this kind of thing was being mooted in the HPC community at large right now — using the power of the computers to program themselves — or at least to take current codes and generate scalable high performance implementations from them. Claus had a cautionary note here, “It’s worth pointing out the obvious, that this kind of amplification process amplifies indiscriminately — that is, if the original code/high level solution is suspect in some way, or the amplification routines themselves have distortions, then the computer-generated new code may create quite different outputs to the original. We found that the number of elves required to validate the computer-generated solutions was often similar to the original programming team.”

Taking a topical line, we raised the issue of cloud computing. “Clouds?” puffed Claus, “I have problems managing the snow, ice, and arctic wind impact on the datacentre supply — why would I want clouds in my facility too?”

We closed by asking how HPC integrated with the traditional aspects of the Claus operations. “Ah,” laughed Claus, “you’ve reminded me of a problem we had a few years back when running aerodynamic optimisations on the reindeer and sleigh combo. Taking into account the individual characteristics of the reindeers, the computer proposed harnessing them up in a different order. We had reindeers on strike for days until we finally agreed to put Rudolph back at the front!”