PC software development for multi-core

PC software development is becoming ever more complex in the wake of multi-core. Software blueprinting provides a way of managing that complexity and exploiting the full power of the latest platforms - right from super-computers through multi-core CPUs down to embedded. The new challenge

Re-inventing the free lunch

Multi-core processors now dominate the market and the trend of exponentially increasing core counts is set to continue for quite some time. In the past each new CPU ran faster than the last by performing a given set of sequential instructions in a shorter period of time. This has come to be known as the performance "free lunch".

The advent of multi-core dramatically changes the fundamental nature of the free lunch and in order to keep eating away at execution times, PC software development must meet this new challenge.

The new free lunch will no longer lead to faster execution of a set of sequential instructions. Instead, future chips will perform ever more tasks concurrently. The reason why this is a huge departure is because now applications themselves are responsible for explicitly dividing the work between the workers and exploiting the latest chips to their full potential.

Concurrency is just plain hard

Existing PC software development languages and tools provide poor support for writing concurrent programs and non-composable threading primitives such as locks, semaphores and critical sections are highly unintuitive leaving programmers to reason at an intractably low-level. This is analogous to writing O-O programs in assembly and non-trivial examples can be just as hard.

The crucial change in PC software development towards concurrent programming has lead industry leaders to the conclusion that the PC software development free lunch is now over. Not only must programmers write these incredibly difficult programs but they must write them in such a way that they will divide their processing between the available cores - the number of which is not known at compile time.

As we shall see later, the infrastructure blueprint supported by the necessary technology has the potential to once again restore the free lunch to PC software development.

What's around the corner?

The arrival of multi-core and all its accompanying tribulations serve to clearly exemplify the deep uncertainty over the form that future PC software development platforms and technologies will take. Not to mention the dangers of becoming locked in by assuming details that are likely to change.

It is likely that in the future there will be further advancements in technology that we could never have forseen today. However, the general solution will always take the same form:

• providing the application programmer with suitable abstractions to avoid undue dependence on any volatile underlying technology
• providing intuitive ways to represent that aspect of the application

Precedents

What high-level languages did for us

The first high-level languages provided neat abstractions for the arithmetic, logic and branching instructions provided by particular processors. These textual abstractions strongly resemble the mathematical algorithms that need to be described and thus provide an intuitive way to represent them.

Abstracting platform specific details such as how an add operation or while loop is implemented means that the same high-level program can be executed on different processors by simply interchanging compilers.

Rise of the GUI builders

GUI builders have been around for some time now and present an ingenious example of a higher-level description that has undoubtedly saved vast amounts of time and money, and greatly increased the complexity of GUIs that can be described.

GUI builders also provide an excellent example of orthogonalizing an application aspect. In the previous example of the high-level language, all of the program was considered as algorithmic content and therefore the whole application was described using a high-level language.

GUI builders took the novel step of separating the orthogonal "GUI appearance" aspect into its own localized description. This then allowed for a different description medium to be used for the GUI appearance than for the algorithmic content and this description medium could be highly specialized for the task. This resulted in the intuitive form design that we know and love today.

A recent example of a GUI builder, Trolltech's Qt Windowing toolkit, provides platform specific libraries beneath the application code that can simply be interchanged to run the same GUI on different platforms. Therefore PC software development could initially take place under Windows and then the application ported to (say) Linux without modifying the GUI description.

Describing Infrastructure

Keeping it local

In the same way that the GUI builder provides a form designer to represent all of that previously dispersed logic that built up the GUI appearance, we need to consider a similar approach for application infrastructure.

Application infrastructure is anything to do with threading, locking, arbitration, messaging and so on. It is widely recognised that trawling through unrelated algorithmic content to search for snippets of infrastructure code is a very inefficient way to go about your PC software development, debugging and maintenance. By localizing this logic in the same way that the GUI form designer localized GUI appearance, we make it a great deal easier to browse and therefore to understand.

The right description

Localizing the infrastructure logic also provides another crucial benefit that we saw with the GUI example. This is the idea of using an optimal description medium to represent the specialized logic with which we are dealing. In the case of the GUI appearance a form designer was most appropriate, algorithmic content was best described with high-level textual language. Infrastructure needs its own description medium and this is the infrastructure blueprint.

An infrastructure blueprint captures all of that synchronization, communication and arbitration logic in an intuitive form that facilitates understanding, manipulation and browsing. In fact, we believe that this is best captured graphically. A graphical representation allows interconnected nodes to show relationships between entities and appeals to our intuitive mental models of real world entities and their interactions. This intuitive description ensures that the gap between description and cognition is as small as practicable.

Prescription or interpretation?

A key property of all of the description media that we have discussed so far is that they are prescriptive. This means that there is a precise procedure to get from the description to the finished article. This means that the high-level textual language, the GUI form description and the infrastructure blueprint can all be translated to code by a machine (i.e. compiler, translator etc.).

Any PC software development description that is not prescriptive, by definition must be interpreted to produce a description that is prescriptive and this requires intelligence. This implies, at least with today's technology, some human intervention.

Diagrams requiring interpretation do not allow a software architect to constrain the finished article as he would like and this inevitably leads to overall design compromise and/or requirement shortfall.

How's your integrity?

A fantastic benefit of GUI builders that is not to be overlooked is the ability to produce a GUI framework and test all of the dialogs work and appear as expected prior to writing any of the back-end processing code. This means that a decent mock-up of the final program can be pulled together to demonstrate what it will look like to customers, gain feedback from users and so on.

This is analogous to the notion of an integrity check in the building industry. Are the rooms the right size? Can the bathroom floor support a full bath of water? and so on. This brings us to the idea of an executable framework.

The infrastructure blueprint can be machine translated with the aid of a supporting technology into an executable framework. This framework can then be stimulated with simple events and we can observe the events propagating throughout the application and determine whether it is operating correctly.

This allows the structural integrity of the application to be confirmed very early in the PC software development so races, deadlocks and so on are detected and fixed at the earliest opportunity.

The majority of the code; the processing algorithms, device drivers, data structures and so on populate this framework rather than being owned by components that are integrated with each other by last-minute, ad-hoc "glue" logic. The framework remains unchanged and therefore its structural integrity is always sound and there are no nasty late integration surprises.

PC is the place to be

The infrastructure blueprint abstracts the details of the underlying platform from the software architect and the logical application is mapped to physical processes as part of the translation process.

This means that exotic targets such as supercomputer or embedded development can always take place on readily available desktop PC hardware. PC software development dramatically improves ease of development, debugging and maintenance. The technology that produces the executable framework must therefore ensure it executes repeatably (albeit faster or slower) across all platforms.