Techniques to maximize memory bandwidth on the Rigel compute accelerator

William J. Tuohy
Graduate College, University of Illinois, Urbana-Champaign
University of Illinois, 2011


   title={Techniques to maximize memory bandwidth on the Rigel compute accelerator},

   author={Tuohy, W.J.},



Download Download (PDF)   View View   Source Source   



The Rigel compute accelerator has been developed to explore alternative architectures for massively parallel processor chips. Currently GPUs that use wide SIMD are the primary implementations in this space. Many applications targeted to this space are performance limited by the memory all, so comparing the memory system performance of Rigel and GPUs is desirable. Memory controllers in GPUs attempt to coalesce memory requests from separate threads to achieve high off-chip bandwidth. This coalescing can be achieved by the programmer if the address mapping bits are understood, so that neighboring threads create memory requests that do not conflict. MIMD hardware as implemented in Rigel avoids the SIMD costs of serialization of conditional execution paths and load imbalance from varying task lengths. These benefits to the execution hardware come at a cost of reduced memory bandwidth, however, as it is difficult or impossible to orchestrate the memory requests in a way that achieves perfect access patterns as can be done with SIMD hardware. When a program can be decomposed statically and the computation does not vary among threads, then Rigel can achieve bandwidth similar to that of a GPU – but these are precisely the types of programs for which SIMD hardware is well suited. When a dynamic task distribution scheme is used to improve load balance, or the computation runs for different amounts of time on different threads, memory bandwidth can suffer greatly as the access pattern is not likely to be well controlled. Thus, for the types of programs for which MIMD hardware is best suited, the memory bandwidth penalty may be significant and reduce the benefits of MIMD’s flexible execution hardware.
No votes yet.
Please wait...

* * *

* * *

HGPU group © 2010-2017 hgpu.org

All rights belong to the respective authors

Contact us: