RetroArch 1.7.2 is live...and may have the answer to emulation latency that we need

[THTB]

@Konqrr @MKK hanzo @tehdrewsus @Juggs @nwo I know I'm missing people, but tag away to get this out there.

I can't remember the exact topic this was discussed in, but there were talks of RetroArch introducing a feature that could improve latency within emulators, and even surpass the latency on original hardware. This feature is called run-ahead, and was slated to be released on version 1.7.2.

Well, today, the update went live! Check out the blog entry here: https://www.libretro.com/index.php/retroarch-1-7-2-released/

Spoiler: Introduction To Runahead

This might just be our biggest release yet, thanks in no small part to the new runahead latency reduction system. This feature has already been all the rage over the Internet. Well known people like Durante of DSfix fame praised it and the popular site Ars Technica has dedicated an entire article to this game-changing feature.

We ran an article on this new feature before, and since then, several facts have changed on the ground which bear pointing out. First of all, several performance improvements have been made since. Secondly, the feature has now been enabled for the vast majority of the RetroArch platform ports.

The versions that have this feature enabled and exposed now includes:

• PlayStation3
• Xbox OG
• Wii
• WiiU
• Nintendo Switch
• Android
• PC (Windows)
• PC (Linux)
• macOS
• iOS

Here are some basic things you should know:

• Every game has a certain built-in amount of lag frames. In order for the runahead system to perform as expected, you should set it to the same amount of frames to read ahead that the game you’re running is working by. So, for example, if a game like Super Mario World for the SNES has a guaranteed 2 frame input lag, for the best results, set Runahead frames to 2.
  You can count the amount of lag frames a game has by using the frame advance feature in RetroArch.
• For playable performance, your system should be at least capable of running the core at twice its regular speed. These performance demands go up commensurate to the amount of frames you want to run ahead. The higher performance you get with a core, the more frames you can run ahead at fullspeed.
• While the runahead system is core agnostic and therefore technically we don’t need to patch up cores in order to work with the runahead system, there are several things that can be done in order to improve performance considerably. To this end, Dwedit has submitted several patches to some of the cores in order to make them perform much better. Some of these cores include (but are not limited to) the Snes9x cores, QuickNES, FCEUmm, Nestopia, Gambatte, and even Mednafen/Beetle PSX.
• There are currently some things you should know about Mednafen/Beetle PSX when it comes to runahead. First of all, in order for this core to work correctly with runahead, you should use the software renderer. The OpenGL and Vulkan renderers are currently buggy with runahead. Second, even after several savestate performance improvements, it is unlikely you will be able to set runahead to higher than 1 frame while still being able to run at fullspeed. This might likely change once our bounty for the Beetle PSX dynarec is finally fulfilled (and on that note, it has already reached $720, and a coder is working on a potential solution)
• An often heard question that has been asked is – will this work on a Raspberry Pi? There is no straight answer to this since it heavily depends on the core’s performance. Based on our performance tests on the PS3 and Xbox OG, QuickNES and Gambatte should be at least two cores that should run at fullspeed with runahead set to 6 frames or less. Your mileage may vary on any of the other cores. The quick rule of thumb is that the faster the core, the higher chance there is to get it to run at fullspeed with more runahead frames.

 

[THTB]

Just tested FB Alpha 2012 core, SFA2, with 2f runahead and second instance on. PC specs are Ryzen 3 1200, GTX 1050ti.

Performance impact is not at all noticeable at those specs, in actuality, as low-spec hardware runs it pretty well, as is. I really hope the Lakka OS updates to 1.7.2 relatively soon, and that it runs comfortably on hardware as weak as the RPi3. Would allow for very viable emulator setups that aren't too expensive to get ahold of.

EDIT: Ran it on my phone (Moto G5 Plus...2.0GHz 8-core), and yep, still groovy.