Many independent cores

I’ve just been at an Intel analyst/reseller/partner symposium, and it’s been rather interesting (quite apart from how wonderful the marble pavements in Dubrovnik are). So, what’s new from Intel?

Well, HPC (High Performance Computing) developments (it has a really good Fortran compiler), the MIC (many integrated cores) architecture, the McAfee acquisition…..

But I want to talk about something related to all this but a bit more way-out. Something that may tie all of it together. This is the idea of the Intel CPU as part of a “system of systems” extending well outside the mere hardware domain. Perhaps this idea starts by building the GPU (specialised Graphics Processing Unit) into the chip rather than as a separate board – for commodity graphics processing, at least; although high end gamers will probably still want a specialised graphics processor – but it goes far beyond this. This on-chip GPU can be accessed for general -purpose programming, although it isn’t much like an ordinary Intel processor.

When you have multiple cores available – potentially in the thousands rather than just tens – the world changes. For a start, in simplistic symmetric multicore designs, memory becomes a bottleneck. However, now something like a data-centric architecture starts to make sense – with all those cores co-existing in a peer network of “systems of systems”. Some cores may form simple multi-purpose processors, others manage memory access, others perhaps provide specialised services – the GPU, random number generation, security services, out-of-band management functions – and it all works in near-real-time, manipulating state data directly.

In fact, although the implementation details are different, Intel has been thinking along exactly these lines with its “concurrent collections” project. To quote from the link given: “our goal in supporting a strict separation of concerns between the specification of the application and the optimization of its execution on a specific architecture is to help ease the transition to parallel architectures for programmers who are not parallelism experts”. That’s good, but the implication is that the logical architecture the programmer writes to may be entirely different to the underlying physical architecture and that allows Intel to escape from the constraints of its x86 architecture without upsetting its customers.

Think of an architecture originally envisaged for graphics applications, but generalised. You could have a ring connecting general processors, specialised co-processors (e.g. for texture rendering) and memory (as many memory paths as you need, no bottlenecks here; the processors have no direct connection to memory). Now, add in specialised processors for IO to the network, random number generation, encryption/decryption, security functions (virus scanning in silicon, perhaps) – and scheduling or recovery functions on tamper-proof silicon that can remain inviolate and operative even when the software running on the processors is failing or under attack. This is more-or-less the vision behind the emerging Intel MIC architecture.

Now, this starts to remind me of another mature approach to parallel processing (with different implementation details again, of course), the IBM mainframe channel architecture, with “channels” (specialised programmable computers) managing IO in parallel to the main CPUs. Channels were just one reason why mainframes still got through lots more real work that the supposedly more powerful desktop PCs in the 1990s. As James R. Reinders (Evangelist and Director for Intel Software) puts it: “people ask me how we’ll use all those cores on our next generation chips? Well, perhaps we’ll harvest some good ideas from the last century mainframe and bring them to the mass market!”

Interestingly, one of the often-overlooked features of the mainframe as a host for of systems management applications is its ability to run monitoring, management and scheduling applications in their own inviolate address spaces. So, if a rogue program is crashing badly or an application is under external attack because of a flaw in its input data validation logic, the misbehaving program, potentially, can be ended and controlling systems can apply corrective logic and get on with running the parts of the workload that aren’t having problems. In Windows, misbehaving low priority tasks can hold resources that stop higher priority tasks proceeding, or prevent user access to a perfectly operational processor just waiting for user input, but these dysfunctional situations are orders-of-magnitude less likely on a mainframe architecture (although systems programmers with the highest levels of access can probably break anything if they try hard enough). If the part of the mainframe and its software that is running a Java VM for a Linux application fails, the Operating System and the Workload Scheduler are still operational and accessible.

This provides an example of what I think Reinders calls “out of band” computing and it could be very useful. It’s an idea that’s worth repeating: imagine being able to run software that is isolated from a failing system but can apply corrective and recovery logic. Imagine being able to run tamper-proof code on a protected processor to identify an attempted security exploit and mitigate its impact. And, as I have already pointed out, this is an approach that now fits well with Intel’s MIC architecture.

So, what does Reinders see as the fundamental issue to address in computing, going forwards? Well, unsurprisingly, delivering a secure computing platform that people can trust. And this will need to be a holistic solution, enabled by hardware – Intel’s MIC architecture can support the subsystems needed to deliver this, using the sort of “out of band” computing I’ve just been talking about. The McAfee acquisition is probably part of this vision (Intel acquired expertise that it needs to build security functionality in silicon) but there’s a lot more to it than that (we probably aren’t looking at running today’s antivirus software in silicon). If Intel does build security enabling technology into the chip, it also needs to promulgate an open software interface to these facilities so that third parties can write software using them. Intel doesn’t, I think, see buying McAfee as a way of locking people into Intel with security (and such idea makes no business sense; people just wouldn’t buy into it).

There’s a management and legislative sell – once security is in silicon, the use of it needs to be regulated and privacy safeguarded. Reinders readily admits that Intel should have done more to explain the secure chip ID and the concerns about privacy that it raised (see here) – but it was, in essence, a necessary idea and people found alternative ways of identifying PCs (MAC addresses e.g.) which still leave privacy issues to be addressed. Intel won’t, Reinders says, make that mistake again. Providing a fundamentally secure platform is too important to put it at risk by trying to make trivial commercial advantage out of it, but getting industry and customer buy-in to a fundamentally vendor-independent initiative will take investment in resolving the people and process issues involved. People issues are often harder to address than, and as important as, any technology issues, something the IT industry keeps forgetting.

If you don’t address privacy and legislative issues from the first – better to legislate for dysfunctional uses of technology initiatives than hope people won’t exploit them if you don’t publicise them – any “secure computing platform” won’t succeed in practice. Reinders mentions a classic example of the sort of issue that can arise. In America, the use of a cardholders zip code to validate the card in high-fraud scenarios (typically, stolen cards are first tested in petrol stations) has been effective in controlling card fraud but is now likely to be disallowed because some idiot decided to use the zip code, in an additional application, for marketing analysis; thus invading the card-holder’s privacy. Now if this use of the zip code had been legally restricted to fraud prevention in the first place…

And I suppose that’s a good place to finish this blog. Intel is no longer just a hardware company (really, it hasn’t been for a long time). It is maturing, I think, into an enabler of business outcomes in the widest sense (although I’m not convinced that everyone in Intel sees it that way yet); and providing a resilient, trusted, secure commodity computing platform is part of this.