In several prior blogs, I’ve tried to frame Intel’s recent acquisitions, new products, and tools evolution as part of one, very big, quite complex emerging story about the many-core future – a story that connects phenomena, markets, and applications happening on the desktop, in the enterprise server room, the cloud, and in the rarefied universe of current peta- and future exascale supercomputers. In the background of this emerging narrative, I’ve returned several times to an Intel experimental project, begun in 2009, called ‘Single-Chip Cloud Computer’ (SCC) – a research architecture that integrates the components of a cloud datacenter into silicon, including many cores, an on-chip message-passing network, and power-management functionality able to turn individual cores on and off and supply them with power appropriate to workloads.
Cloud on a chip
Putting a cloud on a chip is a fascinating, vaguely sci-fi feeling idea – though less fantastic-sounding now that some of this architecture is present on Xeon Phi. It’s also a hugely valuable innovation – though the potential benefits may not seem automatically obvious, even to folks who work regularly with contemporary technologies for desktop and server virtualization, and cloud computing.
As you might expect, however, Intel experts have done some serious thinking about this topic. Few more so than Sebastian Schoenberg, who has a PhD in CS from TU Dresden and was a guest researcher at Cambridge, and is now a Staff Researcher with Intel’s Corporate Technology Group; and his collaborator, technology writer Ken Strandberg. Starting in late 2008, the pair authored a series of whitepapers, clarifying the technology and business case around virtualization on many-core architectures (then referred to as ‘tera-scale’), and examining some of the challenges in using anticipated CPUs in this novel way.
Must-reads on virtualization
The first of these papers — Virtualization in a Tera-Scale Environment – discusses certain technical benefits of pursuing virtualization on many-core platforms, showing that these are self-similar to those evidenced when hardware is virtualized on the macro scale. You can, for example, think in terms of running a VMM (Virtual Machine Monitor) on a many-core chip, and then underneath it, running 5, 10, 20, or more Linux instances, each commanding one or more cores and supporting its own application workload. So the simplest business case for single-chip virtualization may be selective consolidation: with a reduced hardware footprint and lower power costs.
The additional benefits gained from bringing this down to the chip level include versatility, efficiency, simplicity, and manageability. Anyone who works in real cloud environments knows that there’s often an emergent trade-off between the efficiency and simplicity gained by deploying simple OS+application configurations on a single VM, versus the problem of VM proliferation. Many more compute elements can help solve this problem, in part, by making proliferation more the norm – creating a ‘realer’ relationship between available compute power and workload demands, and enabling more-efficient migration of diverse workloads to where their requirements can be provided for most efficiently. Management tools, of course, will need to evolve to match user requirements, providing enough information to support user decision-making, and more likely take a firmer hand in automating and dynamically optimizing workload deployments.
High availability, too, is likely to ‘work’ in virtualized many-core environments, which provide huge de-facto redundancy of compute elements, and the potential for more-rapid switchovers, and different, more-agile methods of heartbeat monitoring, fault evaluation, and recovery than conventional HA systems can now practically employ.
The authors go on to discuss in greater detail the benefits of highly granular many-core virtualization to software development and innovation. They envision a potential future in which virtual appliances – packaging an OS and applications and written to the requirements (not of hardware, per se, but of a much smaller range of available VMMs) become dominant over conventional forms of software with many more external dependencies. By adding the virtualization layer, the market reduces the number of hardware platforms software creators need to worry about, potentially to a mere handful, This, in turn, enables them to focus resources on reliability testing and performance tuning.
Synchronization whitepaper
None of this, of course, is a slam-dunk, as the authors detail in another paper, Synchronization in a Many Core World, produced around the same time. The paper has, interestingly, been mis-filed by Google: confused with another popular paper called Virtualization in a Many Core Environment, which reads something like a draft of the more-elaborate paper described above. So the paper on synchronization may not have received the wider attention it deserves.
The paper then goes into greater detail about the problems that need to be overcome in turning products like Xeon Phi into fully valid SCC-type platforms – for example, the history of difficulties overcome, both on the Intel hardware side and in the Linux kernel, in porting Linux to large numbers of cores. They also describe how virtualizing workloads and putting them on single cores offers a hypothetically important adaptation layer that helps older-school single- and few-core applications live forward, alongside applications written to use many-core facilities, both inside VMs.
Though aging, both these pieces are so forward-looking that they age well, and present an excellent introduction to developers and IT leaders looking forward to how Xeon Phi itself, products incorporating it, and the generations of descendants to follow may change the face of cloud computing in just a few years.
_______________________________________________________________
John Jainschigg is a Geeknet contributing editor, and is CEO of World2Worlds, Inc., a digital agency focused on immersive technology and gaming. John’s initial intro to concurrency was via interrupt and re-entrancy programming at the assembler level on Z80 and 68000-based systems. He wrote concurrent, time-critical packet-switching applications on HP-UX RISC machines in the late 1980s, and since then has worked up and down the client-server stack in Java, C++, PHP, and other conventional and scripting languages, and more recently, in task-specific, state-based, radically concurrent languages like LSL.
