Migrating legacy middleware to multicore environments

Story

February 21, 2011

Charles Rush

Objective Interface Systems

Multicore microprocessors in embedded defense systems are becoming ubiquitous. Embedded systems have specialized requirements, such as heat dissipation and battery life, that restrict the ability to simply crank up the clock speed of a processor. Embedded microprocessor designers grappling with these physical limitations have turned to multicore architectures as a preferred method for continuing geometric performance improvements. Multicore ARM and PowerPC chips are already available, and Intel is pushing its low-power multicore processors into embedded designs. For defense system architects updating legacy systems with new capabilities, incorporating a multicore processor can require an analysis and development effort that extends well beyond the traditional software port.

Unlike the performance increases from boosting microprocessor clock speeds, accessing the performance potential of a multicore processor often requires engineering development efforts to a parallelize software execution. Along with efforts of identifying, expressing, and implementing parallelization, most approaches to parallel software require the explicit management of communications and shared resources. Selecting a set of software components that already addresses these concerns can greatly simplify the transition to a multicore microprocessor architecture.

In particular, the critical but invisible middleware that provides the communication framework for many embedded systems can become a significant asset in simplifying the architecture and design of a multicore system. Software engineers in pursuit of multicore performance often overlook the influence middleware has, and how the proper choice of middleware can significantly improve performance.

How middleware simplifies defense systems architecture

Middleware frameworks evolved to help software developers overcome the inherent complexity of programming for distributed systems. The complexity resulted from the heterogeneity of networks, hardware, operating systems, and programming languages present in many systems. The Common Object Request Broker Architecture (CORBA) is a standards-based middleware that communicates among operating systems, multiple languages (C++, Ada, and Java), microprocessors (x86, PowerPC, ARM, MIPS, and so on), and data transports (Ethernet, PCI Express, shared memory, RapidIO, InfiniBand, and so on). CORBA has been used in defense applications for years because of its flexibility and interoperability, resulting in millions of lines of CORBA code in today’s defense systems. It can be found in defense applications ranging from command and control to weapons systems to air traffic control systems.

A CORBA application is architected as a set of communicating objects, each able to provide services or utilize the services provided by another object. The CORBA middleware handles all of the details of communication between objects. The application is unaware of where an object is physically hosted or how messages are transported among objects. All CORBA object communications are candidates for parallel execution. During a system update, parallel execution can be increased by re-deploying CORBA objects in new processes across several microprocessors or moving them to new multicore microprocessors without requiring application refactoring.

Internal tests show that applications using multicore-enabled middleware can achieve a linear increase in performance as each core is added without rewriting code.

How middleware affects performance

Middleware frameworks can create performance bottlenecks stemming from their design and implementation. Some of the ways that middleware can be a bottleneck include:

Protecting critical sections
Resource usage
Networking

Locks are necessary to keep critical sections of the application or system resources protected from being used by more than one execution thread at a time. However, poorly designed middleware uses locks very inefficiently, for example, too many locks are created or code segments locked are too large. Efficient middleware minimizes the number of locks and ensures that each thread holds the lock for the minimum amount of time.

Middleware can also consume excess resources. For example, if the middleware opens too many file descriptors that identify system components such as communications sockets, it can consume too many resources. This causes the operating system to slow or even halt application execution. Again, efficient middleware will consume minimal resources.

A key component of middleware is the data network transport services that read and write data to the network. How well these services exploit the power of today’s multicore processors plays a major role in determining an application’s performance.

Issues to consider include the speed of each transport and whether the middleware can support concurrent processing across a network interface. It is also important to determine if middleware can use different physical network transports such as PCI, FireWire, shared memory, TCP/IP, RapidIO, ATM, and InfiniBand. A well-designed middleware will include a pluggable transport architecture that places no limit on the number or types of transport that can be used.

Multicore performance simplified with efficient middleware

As critical as the middleware communication framework is, it is often overlooked as an opportunity for improving application performance. Most legacy middleware is unable to take full advantage of today’s multicore processors and can hobble application performance despite careful upgrades to other portions of the application infrastructure. Replacing legacy middleware implementation with multicore-capable middleware, such as the ORBexpress, is a low-cost, low-risk option that can simplify system architecture, enable reuse of legacy source code with a minimum amount of additional programming, and enable increased system performance.

Charles Rush is Senior VP of the Middleware Technologies Group at Objective Interface Systems, Inc. He can be contacted at [email protected].