Whatcookie, one of the lead developers of the PS3 emulator RPCS3, has released a dense video highlighting improvements made to PS3 emulation using the ARM architecture. Whatcookie states in the video that this resulted in PS3 games running up to 60% faster, while reducing power draw by up to 25%.
The Busy Wait Bug
Whatcookie states that they bought an AYN Odin 2 at the end of last year specifically so that they could “install Linux on it and optimize RPCS3 for ARM.” What they identified is that “we’re spending half of our CPU time in this little four-line function; busy wait.” Essentially, this code checks if another thread changed a variable, over and over and over again. While it allows fast identification of changes, it can result in more power draw and load on resources shared between cores.
Adding busy wait to a particular place in the code for x86 devices nearly tripled the performance under specific circumstances. Whatcookie states that, while it depends on the specific hardware, it’s usually running “between 2 to 4GHz, which works out to about a 1 microsecond wait.” So, why is it so much slower on ARM?
When the code was ported over to ARM, the reading of the hardware timer on x86 devices was replaced with reading the hardwire timer on ARM. However, on the AYN Odin 2 that Whatcookie was using, the hardware timer was running at 19MHz, 150 times slower than the reading of the hardware timer on x86 devices. Essentially, a 1 microsecond wait turns into a 150 microsecond wait, and since ARM hardware timers typically run between 10MHz and 1GHz, that wait could be even greater.
Scaling the amount of time spent waiting by the frequency of the timer “fixes” this bug, and results in an average of 25% boost in performance, with an average reduction in power draw by 10%.
Instruction Synchronization Barrier
Within the busy wait function, Whatcookie mentions that the team used the ARM Yield instruction in place of the x86 Pause instruction. This should result in an improvement to the function by indicating to the processor that whatever the thread is currently doing is of low importance, and thus could “yield” to something more important. However, this only worked in devices using Symmetric Multithreading (SMT); almost all ARM devices use Symmetric Multi-Processing (SMP).
Instead, the team pivoted from using Yield to using Instruction Synchronization Barrier (ISB). While not an exact match for pause, it does result in saving a little power. Essentially, the CPU is able to save power by only checking the condition once per several nanseconds, rather than multiple times per nanosecond.
Recompilation
Whatcookie mentions that Nekotekina, the former lead developer of RPCS3, ported the emulator to ARM, but left the project before finishing work on the recompilers. This is foundationally important to running any game at full speed, and left the ARM port with some existing issues that weren’t present on the x86 builds.
Now, this part of the video is dense, as Whatcookie goes into how they fixed every single instruction where x86 did a better job compiling than ARM devices. We’re not going to go into that great of detail here, but essentially dozens of these instructions were recompiled in order to provide better performance on ARM devices.
Core Improvements
Whatcookie goes on to mention that, while these “low-hanging fruit optimizations” showed a great improvement in performance, they wanted something even more; core improvements. This is another dense section of the video, so we’ll cover the three optimizations that were made below.
By speeding up the comparison operations through multiply accumulate instructions -multiplying two comparison results together, and then accumulate them to result in a reduction in instructions executed – Whatcookie was able to speed up the comparison by 22% on ARM mid cores and larger cores, and 16% on the smaller cores.
By speeding up the checksum through unassigned absolute difference and accumulate long (UABAL) – which involves the consumption of two loads, calculating the absolute difference, and accumulating them with one instruction – Whatcookie was able to speed up mid-sized cores by 38%, and the larger cores by 21%.
Rolling up the checksum code when it is large enough – which results in taking up less space in the code cache – grants around a 2% increase to performance.
On ARM devices, all three of these optimizations combined results in a roughly 5% increase in performance, further adding to the increases gained with the previous optimizations.
Scalable Vector Extensions
In another dense section of the video, Whatcookie talks about utilizing Scalable Vector Extensions (SVE) – which changes how comparison structures work to determine if an operation should be kept or zeroed out – to provide specific 128-bit SVE length instructions to offer further optimizations for RCPS3.
RCPS3 is vector-heavy emulator, so by utilizing SVE, Whatcookie was able to observe a 10% performance uplift in a simple loop that utilizes a lot of multiply instructions.
What Does It All Mean?
Over the course of the last several months, Whatcookie and the team working on RPCS3 managed to find and fix several bugs that were present when the emulator was ported over to ARM devices, as well as determine and define several optimizations not being utilized previously. In doing so, they have now given PS3 emulation on Android handhelds a significant boost in performance, while also reducing heat and power draw.
I felt it was important to try and touch upon just how much work and optimization has gone into these improvements, even if it was in substantially less detail than Whatcookie’s actual video. At the end of the day, for those of us rocking ARM devices, PS3 emulation is about to get a whole lot more impressive with RPCS3!
