Following Part 1, here are some more analogies for HPC …
Duh! Clue’s in the name: Big computer
I see this in so many “Intro to HPC” type courses – defining HPC as a computer 1000x more powerful than a desktop computer. Or worse, a computer that costs several million dollars, requires a megawatt of power, and fills a room. For bonus points the weight of the machine or how much cooling water it churns can be used. This is not really an analogy – simply a statement of the fact that HPC usually involves extreme computer hardware (albeit a narrow definition of HPC). But the reader/listener is left clueless as to the reason why anyone would fill a room full of computers and stump up for a $1m/year electricity bill. In fact, I would go as far as to say that this type of description of HPC (“it’s a big computer”) should be banned from the repertoire of any HPC person wishing to retain the community respect. Unless used in conjunction with a solid and inspiring description of the purpose and benefits of HPC.
Not special, just normal: Library
One of the great HPC analogies I have heard is one that describes where HPC should sit in the make-up of R&D organizations, especially universities. This one says that HPC should occupy the same position in any research organization (university) as a library – i.e., a core part of the essential infrastructure and a research tool that can be turned to many projects. A university for the last few centuries without a library? As silly as a modern R&D organization without access to HPC facilities. There are tiers of libraries too. Supporting the university library are national libraries with greater breadth of material. Equally important are the local research group libraries with much more specialized texts that may not be found in the larger more general purpose libraries. And the local libraries have a lower barrier to access. I’m sure the reader can work out the analogies to the traditional pyramid of HPC tiers.
Imagine a silly task: Aircraft vs. Car
One of the favorite hunting grounds for HPC analogies is explaining the nature and usefulness of the capability vs. capacity distinction. First, let me get a common mistake out of the way – I often see people trying to describe capability as the role of a supercomputer and capacity as the role of a cluster. There is no reason why a well architected commodity cluster cannot do capability computing and certainly poorly implemented supercomputers can be useless for capability work.
Usually we start by asking the reader/listener to imagine a task that needs doing/solving. Let’s say we have to move a thousand shoe boxes from one city to another. We can load up a car (or a group of cars if we have a team of willing friends) with boxes and drive them to the new location, and repeat as needed. As the problem gets bigger (more boxes or more distant cities) the cars take longer to complete the task, or more cars are needed. However the cars can still do the job. Now, imagine the destination city is across an ocean. It doesn’t matter how many cars are put on to the job or how much time is allocated, the cars cannot move the boxes across the ocean. But a cargo airplane can. This is capability – a job that cannot be achieved without that platform.
In HPC, capability computing jobs are those that cannot be completed by waiting longer or using a collection of smaller resources. This is often equated to jobs that require the use of the whole supercomputer (or half of it or some other large fraction) – but this is not a general answer to capability. Capability might only require a small fraction of the machine, but needs some special features it has. And not all jobs that use the full size of a system are capability jobs. There is also a great derived analogy – the aircraft can be used for both jobs (assuming availability of runways etc.). And so a capability computing system can be used for capacity work too – but the reverse is not true. Although of course, a system designed for capability might not be as cost-effective when used for capacity workloads.
Another aspect of HPC that cries out for effective analogies is the need to explain why supercomputing needs proper resourcing – i.e., people and software, not just a room filling lump of silicon and copper. One impactful analogy I have heard is to describe supercomputers purchased or deployed without adequate matching investment in software and people as “monuments.” Great to look at, but not very functional. One analogy is to consider a long haul passenger airplane. To deliver its mission, the airplane must be supplemented by an entire ecosystem of pilots, cabin crew (or flight attendants if on a US-based airline), runways, passenger terminals, air traffic control, processes/procedures, etc.
Likewise, HPC needs an ecosystem of people, software, datacenters, I/O subsystems, etc., to deliver its mission. And just like air travel, much of the complexity is in the ecosystem beyond the hardware product. And, here is the important bit, the differentiation and economic impact comes from getting the ecosystem right. Airlines have the same aircraft as their competitors just as companies normally have access to the same HPC technology as their competitors. But, how the staff interacts with the customers, quality of the back-end support, the processes/policies – these are what distinguish one airline from another. Likewise, the software, the support staff, the policies, etc., are what enables each company to gain a competitive advantage over their peers who may be using the same HPC technology.
The HPC Hotel
This analogy is great for explaining many different HPC concepts. Imagine your job is to refurbish a hotel. Clearly this task is easier if you have additional workers – more people means the job can be done quicker. And you can accept contracts to refurbish bigger hotels. But you need to coordinate all these extra workers of course. I’m sure you can see the use of this analogy for explaining parallelism and scalability (decomposition, coordination, scheduling conflicts, resource contention, etc.). You can also use it to introduce special vs. general purpose processors (everyone can do any job vs. combination of plumbers, electricians, plasterers, etc.). It can be used to explain that a variety of skills are needed to make the refurbishment (HPC simulation) effective.
The HPC hotel analogy can be used to show that the job of running a hotel is not the same as the job of designing a hotel is not the same as the job of building/refurbishing a hotel is not the same as staying in a hotel. In the same way, it is silly that one person expects to be expert in using HPC, and writing the applications, and running the cluster, and designing the cluster, and so on. The analogy can also be used to describe areas of differentiation – hotels (HPC) can differentiate from each other on both the rooms (hardware) and the services/staff/policies (support & software).
So, there you go – a light touch run-through of some common HPC analogies. What analogies do you use to describe HPC? Which ones have you found through feedback to be effective? Which ones are best left with those packing boxes that have been in the corner of the datacenter since before anyone can remember?