SOFTWARE STANDARDS FOR THE MULTICORE ERA
The MIT Faculty has made this article openly available. Please share how this access benefits you. Your story matters.
Citation Holt, J. et al. “Software Standards for the Multicore Era.” Micro, IEEE 29.3 (2009): 40-51. © 2009 IEEE
As Published http://dx.doi.org/10.1109/MM.2009.48
Publisher Institute of Electrical and Electronics Engineers
Version Final published version
Citable link http://hdl.handle.net/1721.1/52432
Terms of Use Article is made available in accordance with the publisher's policy and may be subject to US copyright law. Please refer to the publisher's site for terms of use...... SOFTWARE STANDARDS FOR THE MULTICORE ERA
...... SYSTEMS ARCHITECTS COMMONLY USE MULTIPLE CORES TO IMPROVE SYSTEM
PERFORMANCE.UNFORTUNATELY, MULTICORE HARDWARE IS EVOLVING FASTER THAN
SOFTWARE TECHNOLOGIES.NEW MULTICORE SOFTWARE STANDARDS ARE NECESSARY Jim Holt IN LIGHT OF THE NEW CHALLENGES AND CAPABILITIES THAT EMBEDDED MULTICORE Freescale Semiconductor SYSTEMS PROVIDE.THE NEWLY RELEASED MULTICORE COMMUNICATIONS API Anant Agarwal STANDARD TARGETS SMALL-FOOTPRINT, HIGHLY EFFICIENT INTERCORE AND INTERCHIP Massachusetts Institute COMMUNICATIONS. of Technology ...... Pushing single-thread perfor- or for networked collections of computers mance is no longer viable for further scaling (see the ‘‘Requirements for Successful Het- of microprocessor performance, due to this erogeneous Programming’’ sidebar. Sven Brehmer approach’s unacceptable power characteristics.1-3 We define a system context as the set of PolyCore Software Current and future processor chips will external entities that may interact with an ap- comprise tens to thousands of cores and plication, including hardware devices, mid- specialized hardware acceleration to achieve dleware, libraries, and operating systems. A Max Domeika performance within power budgets.4-7 multicore SMP context would be a system Hardware designers find it relatively easy context in which the application interacts Intel to design multicore systems. But multicore with multicore hardware running an SMP presents new challenges to programmers, operating system and its associated libraries. including finding and implementing paral- In SMP multicore-system contexts, pro- Patrick Griffin lelism, dealing with debugging deadlocks grammers can use existing standards such as and race conditions (that is, conditions Posix threads (Pthreads) or OpenMP for Tilera 8,9 that occur when one or more software tasks their needs. In other contexts, the program- attempt to access shared program variables mer might be able to use existing standards Frank Schirrmeister without proper synchronization), and elimi- for distributed or parallel computing such as nating performance bottlenecks. sockets, CORBA, or message passing interface Synopsys It will take time for most programmers (MPI, see http://www.mpi-forum.org).10 and enabling software technologies to catch However, two factors make these standards up. Concurrent analysis, programming, debug- unsuitable in many contexts: ging, and optimization differ significantly from their sequential counterparts. In addi- heterogeneity of hardware and software, tion, heterogeneous multicore programming and is impractical using standards defined for sym- constraints on code size and execution metric multiprocessing (SMP) system contexts time overhead......
40 Published by the IEEE Computer Society 0272-1732/09/$25.00 c 2009 IEEE
Authorized licensed use limited to: MIT Libraries. Downloaded on December 7, 2009 at 11:40 from IEEE Xplore. Restrictions apply...... Requirements for Successful Heterogeneous Programming Successful heterogeneous programming requires adequately addressing providers have created multicore debugging and optimization software the following three areas: a development process to exploit parallelism, a tools, but they are custom-tailored to each specific chip.7,8 This situation generalized multicore programming model, and debugging and optimization leaves many programmers lacking tool support. paradigms that support this model. It became evident decades ago that source-level debugging tied to the programming language provided efficient debugging techniques to the pro- grammer, such as visually examining complex data structures and stepping Development process 9 Multicore development models for scientific computing have existed for through stack back-traces. Raising the abstraction of multicore debugging years. But applications outside this domain leave programmers with stan- is another natural evolutionary step. In a multicore-system context, the pro- dards and development methods that don’t necessarily apply. Furthermore, grammer creates a set of software tasks, which are then allocated to the programmers have little guidance as to which standards and methods provide various processor cores in the system. The programmer would benefit some benefit and which don’t. Domeika has detailed some guidance on de- from monitoring task life cycles and from seeing how tasks interact via com- velopment techniques,1 but there is no industry-wide perspective covering munications and resource sharing. However, the lack of standards means multiple embedded-system architectures. This problem invites an effort to that debugging and optimization for most multicore chips is an art, not a formulate industry standard development processes for embedded systems science. This is especially troubling because concurrent programming introdu- that address current and future development models. ces new functional and performance pitfalls, including deadlocks, race con- ditions, false sharing, and unbalanced task schedules.10,11 Although it isn’t this article’s main focus, we believe that the standards work presented in Programming models the main text will enable new capabilities for multicore debug and A programming model comprises a set of software technologies that help optimization. programmers express algorithms and map applications to underlying comput- ing systems. Sequential programming models require programmers to specify application functionality via serial-programming steps that occur in strict References order with no notion of concurrency. Universities have taught this programming model for decades. Outside of a few specialized areas, such as distributed sys- 1. M. Domeika, Software Development for Embedded Multi-core tems, scientific applications, and signal-processing applications, the sequential- Systems: A Practical Guide Using Embedded Intel Architecture, programming model permeates the design and implementation of software.2 Newnes, 2008. 2. W.-M. Hwu, K. Keutzer, and T.G. Mattson, ‘‘The Concurrency But there is no widely accepted multicore programming model outside Challenge,’’ IEEE Design & Test, vol. 25, no. 4, 2008, pp. 312-320. those defined for symmetric shared-memory architectures exhibited by work- 3. IEEE Std. 1003.1, The Open Group Base Specifications Issue 6, stations and PCs3 or those designed for specific embedded-application IEEE and Open Group, 2004; http://www.opengroup.org/onlinepubs/ domains such as media processing (see http://www.khronos.org). Although 009695399. these programming models work well for certain kinds of applications, 4. B. Vermeulen et al., ‘‘Overview of Debug Standardization Activ- many multicore applications can’t take advantage of them. Standards that ities,’’ IEEE Design & Test, vol. 25, no. 3, 2008, pp. 258-267. require system uniformity aren’t always suitable, because multicore systems 5. L. Adhianto and B. Chapman, ‘‘Performance Modeling of Com- display a wide variety of nonuniform architectures, including combinations of munications and Computation in Hybrid MPI and OpenMP Appli- general-purpose cores, digital-signal processors, and hardware accelerators. cations,’’ Proc. 12th Int’l Conf. Parallel and Distributed Systems Also, domain-specific standards don’t cover the breadth of application (ICPADS 06), IEEE CS Press, 2006, pp. 3-8. domains that multicore encompasses. 6. J. Cownie, and W. Gropp, ‘‘A Standard Interface for Debugger The lack of a flexible, general-purpose multicore-programming model lim- Access to Message Queue Information in MPI,’’ Recent Advan- its the ability of programmers to transition from sequential to multicore pro- ces in Parallel Virtual Machine and Message Passing Interface, gramming. It forces companies to create custom software for their chips. It J. Dongarra, E. Lugue, and T. Margalef, eds., 1999, Springer, prevents tool chain providers from maximally leveraging their engineering, pp. 51-58. forcing them to repeatedly produce custom solutions. It requires users to 7. M. Biberstein et al., ‘‘Trace-Based Performance Analysis on Cell craft custom infrastructure to support their programming needs. Furthermore, BE,’’ Proc. IEEE Int’l Symp. Performance Analysis of Systems time-to-market pressures often force multicore solutions to target narrow ver- and Software (ISPASS 08), IEEE Press, 2008, pp. 213-222. tical markets, thereby limiting the viable market to fewer application domains 8. I.-H. Chung et al., ‘‘A Study of MPI Performance Analysis Tools and preventing efficient reuse of software. on Blue Gene/L, Proc. 20th Int’l Parallel and Distributed Process- ing Symp. (IPDPS 06), IEEE CS Press, 2006. 9. S. Rojansky, ‘‘DDD—Data Display Debugger,’’ Linux J., 1Oct. Debugging and optimization 1997; http://www.linuxjournal.com/article/2315. There are standards for the ‘‘plumbing’’ required in hardware to make multi- 10. E.A. Lee, ‘‘The Problem with Threads,’’ Computer, vol. 39, no. 5, 4 core debugging work, and debugging and optimization tools exist for multicore 2006, pp. 33-42. 5,6 workstations and PCs. However, as with the multicore-programming 11. The OpenMP API Specification for Parallel Programming, OpenMP model, no high-level multicore debugging standard exists. Tool chain Architecture Review Board, 2008; http://openmp.org/wp.
......
MAY/JUNE 2009 41
Authorized licensed use limited to: MIT Libraries. Downloaded on December 7, 2009 at 11:40 from IEEE Xplore. Restrictions apply...... EMBEDDED MULTICORE PROCESSORS AND SYSTEMS
For heterogeneous multicore contexts, multicore-association.org) have published a using any standard that makes an implicit as- roadmap for producing a generalized multicore- sumption about underlying homogeneity is programming model. The MCA deemed impractical. For example, Pthreads is insuffi- intercore communications a top priority for cient for interactions with offload engines, this roadmap, because it is a fundamental with cores that don’t share a memory do- capability for multicore programming. In main, or with cores that aren’t running a March 2008, the consortium’s working single SMP operating system instance. Fur- group completed the multicore communica- thermore, implementers of other standards tions API (MCAPI) specification,11 the first such as OpenMP often use Pthreads as an in a set of complementary MCA standards underlying API. Until more suitable and addressing various aspects of using and man- widely applicable multicore APIs become aging multicore systems. MCAPI enables and available, these layered standards will also simplifies multicore adoption and use. The have limited applicability. exampleimplementationinthisarticle Systems with heterogeneous cores, instruc- shows that MCAPI can meet its stated tion set architecture (ISAs), and memory goals and requirements, and there is already architectures have programming characteris- a commercial version available. tics similar to those of distributed or scientific computing. Various standards exist for this MCAPI requirements and goals system context, including sockets, CORBA, The MCAPI working group’s task was and MPI. However, there are fundamental to specify a software API for intertask com- differences between interconnected computer munication within multicore chips and be- systems (common in distributed and scien- tween multiple processors on a board. The tific computing) and multicore computers. primary goals were source code portability This limits these standards’ scalability into and the ability to scale communication per- the embedded world. At issue is the overhead formance and memory footprint with respect required to support features that aren’t to the increasing number of cores in future required in the multicore system context. generations of multicore chips. While respect- For example, sockets are designed to support ing these goals, the MCAPI working group lossy packet transmission, which is unneces- also worked to design a specification satisfy- sary with reliable interconnects; CORBA ing a broad set of multicore-computing requires data marshalling, which might not requirements, including: be optimal between any particular set of com- municators; and MPI defines a process/group suitability for both homogenous and model, which isn’t always appropriate for het- heterogeneous multicore; erogeneous systems. suitability for uniform, nonuniform, or These concerns justify a set of comple- distributed-memory architectures; mentary multicore standards that will compatibility with dedicated hardware acceleration; embrace both homogeneous and heter- compatibility with SMP and non-SMP ogeneous multicore hardware and operating systems; software, compatibility with existing communi- provide a widely applicable API suitable cations standards; and for both application-level programming support for both blocking and non- and the layering of higher-level tools, blocking communications. allow implementations to scale effi- ciently within embedded-system con- The working group first identified a set of texts, and use cases from the embedded domain to cap- not preclude using other standards ture the desired semantics and application within a multicore system. constraints. These use cases included auto- motive, multimedia, and networking domains. The companies working together in the For due diligence, the working group applied Multicore Association (MCA, http://www. these use cases to reviews of MPI, Berkeley ...... 42 IEEE MICRO
Authorized licensed use limited to: MIT Libraries. Downloaded on December 7, 2009 at 11:40 from IEEE Xplore. Restrictions apply. sockets, and Transparent Interprocess Pro- tocol Communication (TIPC).12 Although MCAPI node 2 Connectionless there are some overlaps, the working MCAPI node 1 Endpoint <2,1> group found insufficient overlap between message Endpoint <1,1> Port 1 Attributes the MCAPI goals and requirements and to <2,1> these existing standards. Attributes Port 1 MPI is a message-passing API developed MCAPI node 3 for scientific computing that can be useful Endpoint <1,2> Endpoint <3,1> Packet channel for closely to widely distributed computers. Attributes Port 2 Port 1 Attributes It is powerful and supports many of the MCAPI requirements, but in its full form it is complex with a large memory footprint. MCAPI node 4 Furthermore, the group communication Endpoint <4,1> Endpoint <3,2> conceptofMPIisn’talwaysamenableto Scalar channel Port 2 Attributes the types of application architectures we Attributes Port 1 found in our use cases. Berkeley sockets are ubiquitous and well understood by many programmers. But Figure 1. The three multicore communications API (MCAPI) communica- they have a large footprint in terms of both tions types: connection-less messages, and connection-oriented packets memory and execution cycles. These com- and scalars. plexities help sockets to handle unreliable transmission and support dynamic topolo- gies, but in a closed system with a reliable performance at the expense of slightly and consistent interconnect such complex- more setup code. Scalars promise even ities are unnecessary. higher performance, exploiting connected TIPC serves as a scaled-down version of channels and a set of fixed payload sizes. sockets for the embedded-telecommunications For programming flexibility and perfor- market. TIPC has a smaller footprint than mance opportunities, MCAPI messages sockets and MPI. But it is larger than the and packets also support nonblocking target for MCAPI: the TIPC 1.76 source sends and receives to allow overlapping of code comprises approximately 21,000 lines communications and computations. of C code, whereas the MCAPI goal was Communication in MCAPI occurs be- one quarter of this size for an optimized tween nodes, which can be mapped to implementation. many entities, including a process, a thread, an operating system instance, a hardware ac- MCAPI overview celerator, and a processor core. A given To support the various embedded-application MCAPI implementation will specify what needs outlined in our use cases, the MCAPI defines a node. MCAPI nodes communicate specification defines three communication via socket-like communication termination types (Figure 1), as follows: points called end points, which a topology- global unique identifier (a tuple of messages (connection-less datagrams);
MAY/JUNE 2009 43
Authorized licensed use limited to: MIT Libraries. Downloaded on December 7, 2009 at 11:40 from IEEE Xplore. Restrictions apply...... EMBEDDED MULTICORE PROCESSORS AND SYSTEMS
control_task data_task1 data_task2 setup communications setup communications setup communications forever { forever { forever { get input from data_task1 sample A-to-D sample A-to-D get input from data_task2 update shared memory perform calculation perform calculations signal control_task send data to control_task update actuator } } }
(a) (b) (c)
Figure 2. Pseudocode for industrial-automation example. The three tasks involved in this implementation are a control task that receives data from two data tasks, analyzes the data, and adjusts the actuator (a); a data task that collects data from the first sensor (b); and a data task that collects data from the second sensor (c).
Industrial-Automation Application allocates shared memory and sends the ad- dress via an MCAPI message to data_ To illustrate the use of MCAPI, we present task1. In step 6, control_task con- a simple example of an industrial-automation nects end points to create channels to the application that must read two sensors on a data tasks, again avoiding potential dead- continuous basis, perform some calculation lock by using nonblocking calls. In step 7, using data from the sensors, and then up- control_task waits for the connection date a physical device’s setting using an operations to complete. MCAPI requires actuator. A multicore implementation for two steps to create channels: first, creating this might comprise three tasks: data collection the actual channels, which any node can for the first sensor; data collection for the sec- do; second, opening the channels, which ond sensor; and a control task to receive data the nodes owning each end point must from the data tasks, analyze the data, and do. Steps 8 and 9 illustrate channel creation then adjust the actuator. Figure 2 shows for end points owned by control_ pseudocode for the three tasks. This example task.Instep10,control_task can highlight the three MCAPI communica- waits for data_task1 to signal that it tion modes. has updated the shared memory, and in Figure 3 shows an MCAPI implementa- step 11 control_task reads the shared tion of control_task. (For brevity, we memory. This rendezvous approach pro- removed variable declarations and error vides lock-free access to the critical section checking.) In step 1, control_task ini- forbothtasks.Instep12,control_ tializes the MCAPI library, indicating its task receives a data structure from node number via an application-defined con- data_task2.Instep13,control_ stant that is well-known to all tasks. In step 2, task computes a new value and adjusts control_task creates local end points for the actuator. Finally, in step 14, control_ communications with data_task1 and task releases the buffer that MCAPI sup- data_task2.Instep3,control_task plied for the packet that was received. uses nonblocking API calls to retrieve remote Figure 4 shows the MCAPI implemen- end points created by data_task1 and tation for data_task1.Step1shows data_task2, eliminating possible dead- the MCAPI initialization, creation of a lock conditions during the bootstrapping localendpoint,andlookupoftheremote phase caused by a nondeterministic execution control_task end point using non- order of the tasks. The nonblocking calls blocking semantics. In step 2, data_ (indicated by the _i suffix in the function task1 receives the pointer to the shared- name) return an mcapi_request_t han- memory region from control_task. dle, which step 4 uses to await completion of Step 3 opens the channel between data_ the connections. In step 5, control_task task1 and control_task.Now,the ...... 44 IEEE MICRO
Authorized licensed use limited to: MIT Libraries. Downloaded on December 7, 2009 at 11:40 from IEEE Xplore. Restrictions apply. void control_task(void) {
// (1) init the system mcapi_initialize(CNTRL_NODE, &err);
// (2) create two local endpoints t1_endpt = mcapi_create_endpoint(CNTRL_PORT_T1, &err); t2_endpt = mcapi_create_endpoint(CNTRL_PORT_T2, &err);
// (3) get two remote endpoints mcapi_get_endpoint_i(T1_NODE, T1_PORT_CNTRL, &t1_remote_endpt, &r1, &err); mcapi_get_endpoint(T2_NODE, T2_PORT_CNTRL, &t2_remote_endpt, &r2, &err);
// (4) wait on the endpoints while (!((mcapi_test(&r1,NULL,&err)) && (mcapi_test(&r2,NULL,&err))) { }
// (5) allocate shared memory and send the ptr to data_task1 sMem = shmemget(32); tmp_endpt = mcapi_create_endpoint(MCAPI_PORT ANY, &err); mcapi_msg_send(tmp_endpt, t1_remote_endpt, sMem, sizeof(sMem), &err);
// (6) connect the channels mcapi_connect_sclchan_i(t1_endpt, t1_remote_endpt, &r1, &err); mcapi_connect_pktchan_i(t2_endpt, t2_remote_endpt, &r2, &err);
// (7) wait on the connections while (!((mcapi_test(&r1,NULL,&err)) && (mcapi_test(&r2,NULL,&err))) { }
// (8) now open the channels mcapi_open_sclchan_recv_i(&t1_chan, t1_endpt, &r1, &err); mcapi_open_pktchan_recv_i(&t2_chan, t2_endpt, &r2, &err);
// (9) wait on the opens while (!((mcapi_test(&r1,NULL,&err)) && (mcapi_test(&r2,NULL,&err))) { }
// begin the processing phase below while (1) { // (10) wait for data_task1 to indicate it has updated shared memory t1Flag = mcapi_sclchan_recv_uint8(t1_chan, &err);
// (11) read the shared memory t1Dat = sPtr[0];
// (12) now get data from data_task2 mcapi_pktchan_recv(t2_chan, (void **) &sDat, &tSize, &err);
// (13) perform computations and control functions …
// (14) free the packet channel buffer mcapi_pktchan_free(sDat, &err); } }
Figure 3. MCAPI implementation of control_task. The work in this task is divided into an initialization phase (steps 19) and a control loop (steps 1014).
bootstrap phase is complete, and data_ except that data_task2 communicates task1 enters its main loop: reading the with control_task using an MCAPI sensor (step 4); updating the shared-memory packet channel. The configuration of the region (step 5); and sending a flag using an packet and scalar channels is virtually identical. MCAPI scalar call to control_task, In step 5, data_task2 populates the data indicating the shared memory has been structure to be sent to control_task, updated (step 6). and in step 6 data_task2 sends the data. Figure 5 shows the MCAPI implementa- Figure 6 shows two candidate multicore sys- tion of data_task2. Steps 1 through 4 tems for this application: one comprising two are essentially the same as for data_task1, cores of equal size, and one comprising three ......
MAY/JUNE 2009 45
Authorized licensed use limited to: MIT Libraries. Downloaded on December 7, 2009 at 11:40 from IEEE Xplore. Restrictions apply...... EMBEDDED MULTICORE PROCESSORS AND SYSTEMS
void data_task1() {
// (1) init the system mcapi_initialize(T1_NODE, &err); cntrl_endpt = mcapi_create_endpoint(T1_PORT_CNTRL, &err); mcapi_get_endpoint_i(CNTRL_NODE, CNTRL_PORT_T1, &cntrl_remote_endpt, &r1, &err); mcapi_wait(&r1,NULL,&err);
// (2) now get the shared mem ptr mcapi_msg_recv(cntrl_endpt, &sMem, sizeof(sMem), &msgSize, &err);
// (3) open the channel; NOTE – connection handled by control_task mcapi_open_sclchan_send_i(&cntrl_chan, cntrl_endpt, &r1, &err); mcapi_wait(&r1,NULL,&err);
// all bootstrapping is finished, begin processing while (1) { // (4) read the sensor // (5) update shared mem with value from sensor sMem[0] = sensor_data; // (6) send a flag to control_task indicating sMem has been updated mcapi_sclchan_send_uint8(cntrl_chan, (uint8_t) 1, &err); } }
Figure 4. MCAPI implementation of data_task1. This task first performs initialization (steps 13), and then continuously reads a sensor, updates a data structure in shared memory, and notifies the control task using an MCAPI scalar channel (steps 46).
void data_task2() {
// (1) init the system mcapi_initialize(T2_NODE, &err); cntrl_endpt = mcapi_create_endpoint(T2_PORT_CNTRL, &err); mcapi_get_endpoint_i(CNTRL_NODE, CNTRL_PORT_T2, &cntrl_remote_endpt, &r1, &err);
// (2) wait on the remote endpoint mcapi_wait(&r1,NULL,&err);
// (3) open the channel; NOTE - connection handled by control_task mcapi_open_pktchan_send_i(&cntrl_chan, cntrl_endpt, &r1, &err); mcapi_wait(&r1,NULL,&err);
// all boostrap is finished, now begin processing while (1) { // (4) read sensor // (5) prepare data for control_task struct T2_DATA sDat; sDat.data1 = 0xfea0; sDat.data2 = 0; // (6) send the data to the control_task mcapi_pktchan_send(cntrl_port, &sDat, sizeof(sDat), &err); } }
Figure 5. MCAPI implementation of data_task2. After initialization (steps 13) this task continuously reads a sensor and then sends updated data to the control task using an MCAPI packet channel.
cores of various sizes. The MCAPI imple- Benchmarking MCAPI mentation can be easily ported to either of To evaluate how well an implementation these candidate systems. The main concern of the specification could meet the MCAPI would be ensuring that code for tasks is com- goals of a small footprint and high perfor- piled for and run on the correct processors mance, we created an example implementa- for each of these hardware configurations. tion of MCAPI and a set of benchmarks...... 46 IEEE MICRO
Authorized licensed use limited to: MIT Libraries. Downloaded on December 7, 2009 at 11:40 from IEEE Xplore. Restrictions apply. Sensor Processor A-to-D Sensor Processor A-to-D
Processor Sensor A-to-D Sensor Memory Processor A-to-D
Memory D-to-A Actuator Processor D-to-A Actuator
(a) (b)
Figure 6. Candidate multicore architectures for industrial-automation example. The first comprises two cores of equal size (a); the other has cores of various sizes (b).
(The implementation and benchmarks are implementation on several multicore devices. also available on the Multicore Association The echo benchmark measures the roundtrip Web site.) latency of communications through a vari- able number of hops, with each one being MCAPI example implementation an MCAPI node. A master node initiates We created the example MCAPI imple- each send transaction, which is forwarded mentation to in a ring over the desired number of interme- diate hops until it returns to the master. determine any MCAPI specification When the master node receives the sent issues that would hinder implementers, data, it reports each transaction’s roundtrip understand an implementation’s code latency. The fury benchmark measures footprint, throughput between a producer node and a provide a concrete basis for programmers consumer node, sending data as quickly as to evaluate their level of interest in possible. The consumer node reports the MCAPI, and total time and the number of receive transac- establish a baseline for benchmarking tions along with the amount of data received. optimized implementations. Summary benchmark results The example implementation (Figure 7) For these results, we didn’t tune the is publicly available and can be compiled example MCAPI implementation for any on computers running Linux, or Windows platform, and we chose a fixed set of imple- with Cygwin (http://www.cygwin.com) in- mentation parameters (number of nodes, end stalled. The example implementation’s archi- points, channels, buffer sizes, internal queue tecture is layered with a high-level MCAPI depths, and so on). common-code layer that implements MCAPI interfaces and policies, and a low- level transport layer with a separate API. This architecture allows for reimplementing MCAPI API the transport layer, as desired. The current MCAPI common code 1,800 lines of code transport layer uses Posix shared memory and semaphores to create a highly portable Transport API implementation. Shared memory transport code 3,717 lines of code MCAPI benchmarks The example implementation shows that Figure 7. Architecture and code size of example implementation. The it’s possible to implement MCAPI with a MCAPI common-code layer implements MCAPI interfaces and policies. small footprint. To characterize performance, The transport layer has a separate API and can be reimplemented as we also created two synthetic benchmarks desired. (echo and fury) and characterized the example ......
MAY/JUNE 2009 47
Authorized licensed use limited to: MIT Libraries. Downloaded on December 7, 2009 at 11:40 from IEEE Xplore. Restrictions apply...... EMBEDDED MULTICORE PROCESSORS AND SYSTEMS
1.4 the example MCAPI implementation used polling. Despite these disadvantages, the 1.3 example MCAPI implementation per- 1.2 formed quite well, and we expect optimized 1.1 versions to exhibit better performance characteristics. 1.0 Figure 8b shows fury throughput mea- 0.9 sured on a high-end quad-core Unix work- 0.8 station running SMP Linux. Because fury
Relative latency 0.7 involves only two MCAPI nodes, only two of the four CPUs were necessary for this 0.6 MCAPI messages Pipes data. We used scheduler affinity to associate 0.5 Sockets each node with a different CPU. This graph 0.4 shows that the throughput in messages per 4 5 6 7 8 9 10 11 12 13 14 second (around 86,000 for 8-byte messages) Number of hops didn’t achieve the highest throughput in bits (a) per second (for example, fury is limited by 87,000 90.00 API overhead for 8-byte messages). But for larger message sizes, the throughput in bits 86,000 80.00 per second was almost two orders of magni- 85,000 70.00 tude greater, with a small degradation in the 84,000 60.00 number of messages per second. Thus, 83,000 50.00 increasing message size by approximately two orders of magnitude increases bits per 82,000 40.00 second by approximately two orders of mag- 81,000 30.00 nitude. Between 64 bytes and 1,024 bytes Messages Megabits per second Messages per second 80,000 per second 20.00 lies an equilibrium point at which the num- 79,000 Megabits 10.00 ber of messages per second and the number per second of bits per second are optimally matched. It 78,000 0.00 8 64 1,024 remains to be seen whether tuning can push Message size (bytes) the crossover of these two curves toward the (b) larger message sizes, indicating that the API overhead is minimal with respect to message Figure 8. Benchmark results: latencies for the echo benchmark (a) and size. But the initial results are encouraging. throughput for the fury benchmark (b). he MCAPI specification doesn’t com- T plete the multicore-programming Figure 8a illustrates the echo benchmark model, but it provides an important piece. for 64-byte data. We collected this data Programmers can find enough capability in from a dual-core Freescale evaluation system MCAPI to implement significant multicore running SMP Linux. The results are normal- applications. We know of two MCAPI imple- ized to the performance of a sockets-based mentations that should help foster adoption of version of echo. The other data series in the standard. the graph compares the sockets baseline to Three active workgroups—Multicore Pro- a Unix pipes version of echo and an gramming Practices (MPP), Multicore Re- MCAPI message-based version of echo. For source Management API (MRAPI), and distances of eight or fewer hops, MCAPI Hypervisor—continue to pursue the Multi- outperformed both pipes and sockets. It is core Association roadmap. MPP seeks to ad- important to emphasize that these results dress the challenges described in the sidebar. were collected on a dual-core processor This best-practices effort focuses on methods with a user-level implementation of MCAPI. of analyzing code and implementing, debug- Thus, sockets and pipes had kernel support ging, and tuning that are specific to embedded for task preemption on blocking calls, whereas multicore applications. These include current ...... 48 IEEE MICRO
Authorized licensed use limited to: MIT Libraries. Downloaded on December 7, 2009 at 11:40 from IEEE Xplore. Restrictions apply. techniques using SMP and threads, and for- 5. ‘‘P4080: QorIQ P4080 Communications Pro- ward-looking techniques such as MCAPI. cessor,’’ Freescale Semiconductor; http://www. MRAPI will be a standard for synchroni- freescale.com/webapp/sps/site/prod_summary. zation primitives, memory management, and jsp?fastpreview=1&code=P4080. metadata.ItwillcomplementMCAPIin 6. ‘‘Intel Microarchitecture (Nehalem),’’ Intel both form and goals. Although operating sys- 2008; http://www.intel.com/technology/ tems typically provide MRAPI’s targeted fea- architecture-silicon/next-gen/index.htm. tures, a standard is needed that can provide a 7. D.C. Pham et al., ‘‘Overview of the Architec- unified API to these capabilities in a wider ture, Circuit Design, and Physical Implementa- variety of multicore-system contexts. tion of a First-Generation Cell Processor,’’ The Hypervisor working group seeks to IEEE J. Solid-State Circuits, vol. 41, no. 1, unify the software interface for paravirtual- 2006, pp. 179-196. ized operating systems (that is, operating sys- 8. IEEE Std. 1003.1, The Open Group Base tems that have been explicitly modified to Specifications Issue 6, IEEE and Open interact with a hypervisor kernel). This stan- Group, 2004; http://www.opengroup.org/ dard will allow operating system vendors to onlinepubs/009695399. better support multiple hypervisors and 9. OpenMP API Specification for Parallel Pro- thus more multicore chips with a faster gramming, OpenMP Architecture Review time to market. Board, May 2008; http://openmp.org/wp. We believe that multicore-programming 10. CORBA 3.1 Specification, Object Manage- model standards can provide a foundation ment Group, 2008; http://www.omg.org/ for higher levels of functionality. For exam- spec/CORBA/3.1. ple, we can envision OpenMP residing 11. Multicore Communications API Specification, atop a generalized multicore-programming Multicore Association, Mar. 2008; http:// model, language extensions for C and C++ www.multicore-association.org/request_mcapi. to express concurrency, and compilers that php?what=MCAPI. target multicore standards to implement that 12. TIPC 1.5/1.6 Protocol Specification, TIPC concurrency. Another natural evolution to Working Group, May 2006; http://tipc. programming models, languages, and com- sourceforge.net. pilers would be debugging and optimization tools that provide higher abstraction levels Jim Holt manages the Multicore Design than are prevalent today. With MCAPI, it Evaluation team in the Networking Systems could also be possible for creators of debug- Division at Freescale Semiconductor. His re- ging and optimization tools to consider how search interests include multicore-programming to exploit the standard. MICRO models and software architecture. He has a PhD in computer engineering from the ...... University of Texas at Austin. He is a senior References member of the IEEE. 1. M. Creeger, ‘‘Multicore CPUs for the Anant Agarwal is a professor in the Masses,’’ ACM Queue, vol. 3, no. 7, 2005, Department of Electrical Engineering and pp. 63-64. Computer Science at the Massachusetts 2. J. Donald and M. Martonosi, ‘‘Techniques Institute of Technology, where he is also an for Multicore Thermal Management: Classi- associate director of the Computer Science fication and New Exploration,’’ Proc. 33rd and Artificial Intelligence Laboratory. In Int’l Symp. Computer Architecture (ISCA addition, he is a cofounder and CTO of 06), IEEE CS Press, 2006, pp. 78-88. Tilera. His research interests include com- 3. D. Geer, ‘‘Chip Makers Turn to Multicore puter architecture, VLSI, and software Processors,’’ Computer, vol. 38, no. 5, systems. He has a PhD in electrical engineer- 2005, pp. 11-13. ing from Stanford University. He is an ACM 4. S. Bell et al., ‘‘TILE64 Processor: A 64-Core Fellow and a member of IEEE. SoC with Mesh Interconnect,’’ Proc. Int’l Solid-State Circuits Conf. (ISSCC 08), IEEE Sven Brehmer is president and CEO of Press, 2008, pp. 88-89, 598. PolyCore Software, a company providing ......
MAY/JUNE 2009 49
Authorized licensed use limited to: MIT Libraries. Downloaded on December 7, 2009 at 11:40 from IEEE Xplore. Restrictions apply...... EMBEDDED MULTICORE PROCESSORS AND SYSTEMS
multicore software solutions. He has many Patrick Griffin is a senior design engineer different technical interests, including em- on the software team at Tilera. His research bedded systems software, multiprocessing, interests include parallel-programming mod- and alternative energy, especially multicore. els and high-speed I/O for embedded He has an MS in electrical engineering from applications. He has a MEng in electrical the Royal Institute of Technology, Sweden. engineering and computer science from the He is the founding member of the Multicore Massachusetts Institute of Technology. Association and the MCAPI working group chair. He is a member of the Multicore Frank Schirrmeister is director of Product Association. Management in the Solutions Group at Synopsys. His research interests include Max Domeika is an embedded-tools con- electronic system-level design and verifica- sultant in the Developer Products Division at tion, particularly presilicon virtual platforms Intel, where he builds software products for software development, architecture ex- targeting the Embedded Intel Architecture. ploration, and verification. Schirrmeister has His technical interests include software devel- an MS in electrical engineering from the opment practices for multicore processors. He Technical University of Berlin with a focus has a master’s degree in computer science on microelectronics and computer science. from Clemson University and a master’s He is a member of the IEEE and the degree in management in science and tech- Association of German Engineers (VDI). nology from the Oregon Graduate Institute. He co-chairs the Multicore Programming Direct questions and comments about Practices working group within the Multi- this article to Jim Holt, Freescale Semi- core Association. He is the author of conductor, 7700 West Parmer Lane, Software Development for Embedded Multi- MD:PL51, Austin, TX 78729; jim.holt@ core Systems. freescale.com.
...... 50 IEEE MICRO
Authorized licensed use limited to: MIT Libraries. Downloaded on December 7, 2009 at 11:40 from IEEE Xplore. Restrictions apply. Authorized licensed use limited to: MIT Libraries. Downloaded on December 7, 2009 at 11:40 from IEEE Xplore. Restrictions apply.