Legacies – Yours, not Tony Blair’s!
What to do with old code is one of the most familiar – and dreaded - problems in computing. Whether it is programs of “genuine historical importance”, or whether it is those applications that you just need to have around “because”. . . they all need to be ported to the new system. Can they run on it without effort or will a lot of work have to be done to make it execute at all? And will it integrate with the new applications from X, and so on and so on?
Of course, all pre-existing code becomes legacy code the moment that migration to a new architecture is decided upon. Moving to HPC/HFC on multi-core is going to give rise to many of the same issues as with any conventional migration process, and in spades too! To that extent many of the processes, business and otherwise, that will have to be undertaken are familiar.
Because of the inevitability of the move to multi-core and its sheer scale, all sections of industry are going to have to address the issues very soon, and start getting the necessary processes underway. The questions to be asked aren’t simply going to be those encountered in migrating legacy code to a faster processor, the architectural shift is going to be much more than a hardware change; it will bring with it a change in software paradigms. Program architects, programmers and applications designers at all levels are going to have to start to “think parallel”.
Companies such as HP, IBM, Microsoft, Intel are expending a great deal of time and effort to facilitate the migration. Much effort is currently going into how to characterise the different types of processes that underlie most software problems. This is in itself a massive, hugely interesting and absorbing problem. The various applications that we all run, whether on a supercomputer or on an embedded system, have to be identified, classified according to various schemas and then translated into processes using common fundamental building blocks. We have long known that the number of these basic components is, in principle, finite and fairly few in number. For scientific, technical and similar areas (including gaming) these turn out to centre around a set of algorithms some of which we have known about for well over fifty years. Other classes of application are presently the subject of much hot debate.
But this isn’t an arcane debate, it will affect every business every domestic user, every mobile, every vehicle, every train, every plane, and so on and so on. The task is enormous.
Once the debates are resolved the algorithms then have to be mapped onto the new hardware architectures and the whole provided to the average user as a toolkit in a way that they can use without much difficulty. Anything less will impact the adoption curve for multi-cores. Companies including Intel, AMD, RapidMind and others are looking to provide all or part of the toolkit that will both construct parallel applications for HPC/HPF and will help in the migration process. Most address a specific architecture or architectures, none yet supports all.
We will return to these issues and to some of those surrounding the development of new applications in future articles. We will also be looking at the offerings of these and other companies and seeing how they meet the challenges. The message to be taken from here is that the tools are being built to help the migration, but business can help itself, and indeed must do so, by addressing the issues sooner rather than later. If industry starts now it can begin with a relatively small team and avoid having to make huge changes over a short period with the concomitant costs. That, of course, is the rationale behind Bloor and Concertant providing a specialised HPC service.