After more than three decades of operations building and selling numerical software, the Numerical Algorithms Group (or NAG as it’s more commonly known) has started a new effort to teach the world how to program in parallel. Responding to changes in computing at both ends of the spectrum, the company is positioning itself as the place to go, not just for shrink-wrapped libraries, but also for education and expertise in how to program in parallel, and even for expert advice on how to buy, build and run your own supercomputer. HPCwire talked to Andrew Jones, vice-president of HPC business at NAG, on what he has in mind for this new business and how he sees the future of HPC and parallel programming shaping up.

But first, a little history. NAG is an odd organization. One of the company’s most interesting characteristics is its longevity. In general computing, it is hard to list more than a handful of companies that are over 30 years old; but in HPC, it’s nearly impossible. The roots of the company go back to 1970 when Brian Ford launched the NAG project as a collaboration between four universities in the UK: Nottingham, Manchester, Oxford and Birmingham. The Nottingham Algorithms Group changed its name to the Numerical Algorithms Group when it moved to Oxford in 1973, and was transformed into a company in 1976. NAG’s first products were software for numerical computation and statistical analysis, and included the NAG Algol 60 and Fortran Libraries, released in 1971. Over the years the company added new libraries with support for new languages, its own compilers, and visualization tools. Today the company lists over 13 products in five families in its offering.

The second thing that is striking about NAG, and probably an important factor in its longevity, is that it is a non-profit company with several faces. The Numerical Algorithms Group Ltd is the UK parent of an organization that includes two other operating companies: the Numerical Algorithms Group Inc. (US), and the Nihon Numerical Algorithms Group KK (Japan). Collectively, these are referred to as the NAG Group. It is formally designated as a company limited by guarantee, which is a British structure used primarily for non-profit organizations that require corporate status. The company has about 300 members, including contributors to the NAG libraries, current and past staff, and technical experts with a close connection to the company. The organization’s technical excellence is driven by the spirit of collaboration that characterized the Nottingham Algorithm Group before incorporation, and this was a key factor to doing business as a nonprofit.

The company’s most recent initiative is its new HPC Business, headed up for NAG by Andrew Jones in the UK. NAG describes his role as being to lead “the growth of the HPC business, developing strategic relationships within the HPC community — including users, buyers, service providers, software developers and hardware suppliers.” Jones’s business is an HPC consultancy then, and like many changes in business direction, this one didn’t arise out of a vacuum. “NAG’s core is numerical software engineering,” says Jones. “Consulting services, again based on NAG’s core of numerical software engineering, have grown steadily over the last decade or so and, with the recent step up into large contracts like HECToR, are becoming comparable in size to our product-based business.”

Jones and I exchanged a few emails on NAG’s new venture, where we talked about the different aspects of the consultancy business.

When you look at who your customers are in the consultancy, are you thinking of the traditional high end of HPC or the mid to low end?

Our heritage and expertise covers both ends of the HPC spectrum. We have a strong position because the customer volume of our core products are at the low-to-mid range, giving us a clear understanding of the business issues at this scale, but we are actively involved in multiple HPC services at the Top20 scale too.

We already have good business assisting people with the move of commercial software to multicore systems. With our HPC business, we are looking to support those who have software that needs to adapt to manycores, either hundreds of multicore chips now or true manycores on a chip in the near future. This is where new algorithms and engineering issues such as scalability will reap rewards for performance and productivity.

[At the high end], NAG is part of the consortium that runs the UK’s HECToR service. We provide the CSE element of the service — 120 person-years over six years. We plan to focus on the larger end of the market, not just the Top20, but let’s say “Top1 – Top1000 scale” rather than the 16-way systems. There are very few companies able to offer consulting in this end of the market backed by track record and volume of expertise.

In addition to computational science expertise, you are going to build out a business side to help with acquisition and management. Can you describe this aspect of the business?

Just as programming HPC systems is a specialist activity, so often is buying them. In fact it is wider than that. Understanding how HPC best serves business objectives, what kinds of HPC solutions will deliver the best returns, and the process of procuring and reviewing service delivery are all areas where there are many anecdotes of people being “burnt” by doing it themselves, rather than using experts.

I often try to explain this by noting that just because an HPC facility/service is built on top of computers does not mean that it is like a laptop. In fact it is more like a specialist experimental facility or process engine. With HPC, the whole is very different from the collection of parts.

Add to this the complexities of procurement law for public bodies, the diversity of HPC solutions on the market, the pace of change in the industry, etc. All this points to the value experts can add to the HPC strategy and procurement of a business.

NAG’s value is that we have a strong view of the market and the technology expertise (the diversity/complexity issue); we trade on our independence and integrity (the trust issue); and we have the experience (procurement process issues). We can get involved at all stages of the process. For example, we provide ongoing “technology watch” support, or market surveys in support of planning the strategy and procurement. We can support the procurement process itself, through benchmarking, tender evaluation, solution negotiation, etc. We can also come into an existing setup and perform an independent review, asking what can be changed to provide a better business benefit from the HPC service. And of course, we can provide CSE support as part of an HPC service.

Do you yet have a sense for which dimension of your business is going to resonate most with customers: education or code work? How would you like to see this shape up over time?

Currently, we anticipate more interest in the code work and procurement support, although the training need has repeatedly been raised as we meet people in the community.

What is your approach to growing this business?

We intend to take a strategic approach to this business, that is to grow steadily by looking for collaborative engagements that match well to NAG’s key competencies. HECToR is currently the largest-profile engagement, and some of our engagements will always remain non-public of course, but the key is to follow our tradition. Just as NAG has built a reputation for dependability and numerical excellence in our software components, we are building a reputation for integrity and expertise in our HPC services. We expect to run our core software and consulting activities in integration although clearly with the creation of my own position, NAG has shown its commitment to the HPC consulting/services business.

Does your experience at the traditional high end of HPC translate all the way down to parallelism in a socket? What are some of the differences in technology and approach at the far ends (outside the obvious… you won’t use MPI within a socket, for example)?

Yes, the high-end experience does translate down to socket-level parallelism because single-socket parallelism is needed for best performance at the high end now too. Think of quad-core Cray XT systems, for example, like the one NAG will support under the HECToR contract.

In terms of different approaches, three things come to mind. First, the mantra for the many nodes paradigm is to break the data domain up as much as possible and look for algorithms that minimise the exchange of data between nodes (to reduce the effects of limited interconnect bandwidth and latency), whereas the many threads in a node paradigm is increasingly about sharing data (or rather getting many threads to work on a common lump of data) as much as possible in order to support better load balancing, and recognising that the number of threads/cores/FLOPS is increasing much faster than memory capacities.

Second, the standards and practices issue. For instance, the standard for many-node work is pretty much set as MPI. (Yes, there are the various PGAS approaches for example, but MPI is massively dominant). However at the socket/node level, there is much less consensus on the de facto standard, and this end will be more strongly affected by standards coming in from outside traditional HPC, e.g., Ct, TBB, CUDA, threading, etc.

Third, the challenges for the future at each end are different. At the many-code end, we see all the challenges posed by the exascale and petascale programs, i.e., scalability, fault tolerance, I/O. At the manycore end, we see the challenges being the plethora of choices in front of the programmer — libraries/middleware layers, threading models, whether to support SSE/GPU/Larrabee/streaming or just “traditional” multicore, or worse, the “sit back and hope”approach. At the manycore end, we are also looking for a very lightweight (programmer effort and runtime layer) flexible (e.g., dynamic thread count) parallel model. I don’t see a clear winner for that yet.

Can you give us an idea of what an engagement with NAG is like? What are some successes you’ve already had?

Perhaps our best known example is AMD, where NAG and AMD have worked together for around six years now to create, develop and support the numerical software stack for the Opteron processor family, especially ACML but also the basic libm. This is a close collaborative project working as an integrated team across both organisations utilising the strengths of each, for example, the low-level hardware optimisations from AMD and the algorithmic expertise of NAG.

It’s worth noting that NAG has also worked in similar close collaboration with Clearspeed for their CSXL [math library]. NAG has even played a role in Intel’s MKL library and IBM’s Cell software stack, and partnered with other system vendors as well. This shows both the widespread applicability of NAG’s expertise across processor types, but also our vendor neutrality and impartiality, which is invaluable in our providing procurement consulting to customers.

It seems fairly certain that, without a right-hand turn in chip technology, multicore sockets are here to stay for a while. In some fixed and relatively short period of time — say, seven years — mainstream developers will have completed their learning process in the basics of parallel programming. Does your consultancy have a future after that?

Yes, I think it will have a future well beyond the immediate years. As you say, basic parallel programming will start to become more common. But look at HPC. Basic parallel programming is quite common across scientific communities that use HPC. However, the skills required to get performance — e.g., scalability — are still specialised. I see a similar situation for many years after the basic ability to write multi-threaded code becomes widespread. That is multicore-enabled code may become commoditized as you say, but performance and reliable engineering for high thread/core count will remain a specialist skill.

The theory goes that as people’s expertise matures, they develop tools to encapsulate that expertise for the wider market. That has not really happened in HPC over a couple of decades yet — think automagically parallelizing compilers, etc. I think tools will emerge to reduce the level of expertise needed in some places, but I remain convinced that they won’t remove the need for expertise in the next couple of decades either.

As you plan for the kinds of expertise you’ll need, how important is acceleration going to be to the future of parallel and high performance computing? Are customers asking about this expertise, or is this something that is still taking off and customers really aren’t ready for yet?

Not acceleration as such, but heterogeneity and SIMD style programming certainly. We have some SIMD expertise already, covering traditional vector systems (we support a Cray X2 as part of HECToR), Cell, Clearspeed, and GPU. Some of this arises from vendor contracts to develop software for those systems, some from the expertise of our staff from prior specific projects. We will develop more as we need, perhaps keeping slightly ahead of anticipated demand. Customers are talking about this kind of expertise, but it has not yet matched the “traditional” multicore volume yet.

The HPC community is fairly small and expertise can be hard to come by. How will you recruit the skills you need?

As we identify needs, we either recruit new expertise or train existing staff. In many cases some of our staff have experience from previous projects (e.g., Clearspeed, Cell, GPU). Our engagement with universities, from MSc/PhD programmes to training courses to collaborative research helps to grow future students, and helps us identify strong candidates. It’s maybe worth cautioning that in many cases it is a false assumption that HPC centres or universities have a plethora of skilled HPC people waiting to be employed. In many cases, the HPC centres are themselves seeking skilled staff.