a minimum. Even where instructions exist with the same behaviors, they do not have the same instruction names, so this must be mapped as well. IBM provides compiler intrinsics which take care of this mapping transparently as part of the development toolkit. In many cases, however, a directly equivalent instruction does not exist. The workaround might be obvious or it might not. For example, if saturation behavior is required on the SPU, it can be coded by adding additional SPU instructions to accomplish this (with some loss of efficiency). At the other extreme, if Java floating-point semantics are required, this is almost impossible to achieve on the SPU processor. To achieve the same computation on the SPU might require that an entirely different algorithm be written from scratch. The most important conceptual similarity between VMX and the SPU architecture is supporting the same vectorization model. For this reason, most algorithms adapted to Altivec will usually adapt successfully to the SPU architecture as well. Local store exploitation Transferring data between the local stores of different SPUs can have a large performance cost. The local stores of individual SPUs can be exploited using a variety of strategies. Applications with high locality, such as dense matrix computations, represent an ideal workload class for the local stores in Cell BE. Streaming computations can be efficiently accommodated using software pipelining of memory block transfers using a multi-buffering strategy. The software cache offers a solution for random accesses. More sophisticated applications can use multiple strategies for different data types. References The Cell Project at IBM Research Optimizing Compiler for a CELL Processor Using advanced compiler technology to exploit the performance of the Cell Broadband Engine architecture Compiler Technology for Scalable Architectures Cell BE architecture Compilers Vaporware