There are some restriction caused by the CBE architecture. Programming a SPU can be compared to programming a microcontroller:
- Small local-store of SPUs: Only 256 KByte of local-store are available on a SPU which is moreover shared by data and instructions. Because of this a economic stewardship of available resources is needed.
- No underlying OS: The operation system is running on the PPU, but not on the SPUs. Although the OS also manages the SPUs, there are some things which are missing or have to be done in a very performance decreasing and complex way. E.g. there is no support for several threads on one SPU (unless you program it yourself) and most of the system-calls are delegated to the PPU.
- Limited I/O-Capabilities: File-operations are only possible on the PPU. So if you want to store data of an SPU into a file, you have to send it to the PPU who then stores the data into a file. Main-memory is managed by the PPU and the SPUs can only read from or write into the main-memory. Allocation of main-memory has to be done by the PPU.
All Buffers used in send- or receive-functions have to be aligned at a 16-byte boundary (for better performance a 128-byte alignment is recommended). This restriction cannot be circumvented.
DMA-calls only transfer data in chunks of 16 bytes. Send-receive operations and DMA-get-operations provided by this library hide this restriction by the use of intermediate buffers. But you should keep this restriction in mind because to gain maximum performance the size of data to be transfered should be a multiple of 16 bytes.
