Dirty Optimization Secrets (C for Playdate)

These optimization tricks were discovered by @stonerl while working on a full-speed gameboy emulator for the Playdate. While they are not the typical tips for optimizing games, they can be especially helpful for high-performance tasks like emulators, simulations, renderers, or codecs. The Playdate's CPU is fast but its memory access speed is slow, particularly for memory not in the cache.

This means that code primarily operating on registers and not loading lots of data will perform well, even if it has many loops and branch mis-predictions.

One key finding is that the -O3 optimization flag is not always the fastest; -Os might be better. Additionally, the Playdate's instruction cache is small (4KB for Rev A and possibly 16KB for Rev B). To maximize performance, core code like the emulator interpreter loop or fragment renderer should be compressed and fit within the 4KB cache. Rare operations or edge cases can be placed elsewhere.

Contiguous placement of core code in the memory is crucial. This can be achieved by using the __attribute__((section(".text.your-section-name-here"))) on each core function, ensuring the linker places them in one contiguous section. Custom linker scripts can be used to place code from certain files in specific spots. The code's size can be checked to ensure it fits within the instruction cache.

Playdate has a small instruction cache, so code should be compressed to fit within it. If the code doesn't fit, it will be slower. The Playdate's tightly-coupled memory (TCM) is faster than normal memory. The stack sits in the TCM area, so if code operates on a struct for a while, it can be worth copying it onto the stack and operating on it there, then copying it back.

To store data permanently on the stack, store it on the low address end of the stack (dtcm_mempool) instead of the heap. This avoids the need for two memcpy operations. Ensure there is a canary at the start and end of dtcm_mempool and check it at least once per update to prevent stack overflow corruption. In some cases, code can also be placed on the stack or in the dtcm_mempool. However, this requires manual copying to a TCM region, as the Playdate does not automatically put code in the TCM region.