Differences in performance between RetroArch and Standalone emulators.

[Apaczer]

#279 (reply in thread)
@Rezzy-dev
"Use Sonic 2 as a benchmark for PicoDrive -- you'll see the speed difference quite clearly. For MAME/FBA, try Pretty Soldier Sailor Moon (this is an advanced arcade title, quite heavy in graphics and sound). For mGBA and gPSP, Teen Titans."

Hi, regarding does differences between RetroArch and stock emulators:
The Sonic 2 [MD] (Picodrive) - I did not see difference in performance during gameplay (at least not in first level)
Teen Titans [GBA] (gpSP) - it seems a problem with an engine in the emulator itself, stock nor RA work at all with this game (it would be a good idea to post an issue on gpSP's github)
Teen Titans [GBA] (mGBA libretro) - not recommend to play GBA games on that core if you go for performance (see updated wiki's page, so it is nono for this game on Miyoos)
Pretty Soldier Sailor Moon [MAME libretro] - this core is least optimazed of all available cores for Miyoo-arm32, did you try stock FBA? Would recommend to play 8-bit titles with MAME cores if any (Bosconian runned quited well).

[Rezzy-dev]

The Sonic 2 [MD] (Picodrive) - I did not see difference in performance during gameplay (at least not in first level)

What device are you using? I have a PowKiddy Q90, and the performance difference was clear to see: Sonic 2 performed at about a third the speed it was supposed to, that it performs on the stock Miyoo PicoDrive. The movement and game speed was slow and the sound was stuttering (fighting to catch up).

Teen Titans [GBA] (gpSP) - it seems a problem with an engine in the emulator itself, stock nor RA work at all with this game (it would be a good idea to post an issue on gpSP's github)

This wasn't the only serious problem I've encountered with gpSP. Quite a few games crash during gameplay, including Batman Begins (at the fire scene on the first stage). But this is a gpSP problem, not a RetroArch one.

I don't consider gpSP a stable emulator (yet). It needs a lot more work.

Teen Titans [GBA] (mGBA libretro) - not recommend to play GBA games on that core if you go for performance (see updated wiki's page, so it is nono for this game on Miyoos)

I see... :/

Remind me, again, why did we get rid of the VisualBoyAdvance (VBA-M) core? 🙄

Pretty Soldier Sailor Moon [MAME libretro] - this core is least optimazed of all available cores for Miyoo-arm32, did you try stock FBA? Would recommend to play 8-bit titles with MAME cores if any (Bosconian runned quited well).

Stock FBA was is on the borderline with this game -- just able to play it at normal speed. So this game is good for benchmarking performance. But the game was playable on stock MAME (MAME4All), and frame-by-frame slow on RetroArch MAME, unplayable. Huge difference in performance!

[Rezzy-dev]

I've made no other tweaks to either RetroArch itself or the PicoDrive core in RetroArch.

Hmm... On second thought, this makes me wonder if maybe the stock PicoDrive that came with the Miyoo CFW had some custom settings set to improve performance... 🤔

But looking at the config file here, no, I can't see anything in particular. In fact it seems to have "16bit accurate" rendering and "44100 Hz stereo" sound turned on by default, which would only serve to slow it down, not increase its performance.

I think RetroArch does have a performance hit when it comes to emulation. I think the extra, uniform layer that the RetroArch system and its cores run on does have a performance cost. I think that makes logical sense.

[freq-mod]

@Apaczer idk what black magic you have done to your device, RA Picodrive is much slower than standalone 1.99 😂

Demons of Asteborg run at perfect 60 fps on standalone, on RA it's howering around 45 ~50 fps. Same with Alien Soldier

[Apaczer]

Here is basic setup (cfg/opt files) for Picodrive in Retroarch (in Pico I've set renderer=fast ; audio_resampler=22050 ; frameskip=auto), the global settings as in wiki's page.
cfg+opt.zip

There seems to be some slight audio disproportions between standalone emu and RA but the performance should be on par.

[Rezzy-dev]

By "audio disproportions" do you mean the music crackling (the audio fighting to catch up) on the RetroArch PicoDrive? Check the framerate, too. I think you'll find that RA Pico runs at a much lower framerate, and that's with the renderer set to "fast", not "accurate", and the sound quality halved, too.

So, like I said, about a third of the standalone's performance.

[Apaczer]

that might be only due to downsampling on RA (no crackling) I can't really compare without audio extracting. Alien Soldier runs just fine in 1st level.

[Rezzy-dev]

My question is a practical one:

If RetroArch gives me all the same emulator options as the stock emulators for Miyoo, but with worse performance, what's the point of my using RetroArch on Miyoo (unless I am syncing between my PC and Miyoo RetroArch library)?

At this point in development, I really don't see the practical use for RetroArch on Miyoo.

[salvacam]

My question is a practical one:

If RetroArch gives me all the same emulator options as the stock emulators for Miyoo, but with worse performance, what's the point of my using RetroArch on Miyoo (unless I am syncing between my PC and Miyoo RetroArch library)?

At this point in development, I really don't see the practical use for RetroArch on Miyoo.

Some cores offer the same performance and you will have the same interface.

Also surprisingly o2em runs better on Retroarch than if you compile the RG350 version
https://boards.dingoonity.org/gcw-zero-emulation/port-requestpossibility-o2em/

Another advantage is that all the code is on github. For that reason alone it is preferable. I prefer a non-perfect emulator but with accessible source code than a perfect emulator but without source code.

[Rezzy-dev]

I'm hunting down the sources for the current main Miyoo emulators. I have PokeMini and PicoDrive so far (just managed to successfully assemble and build PicoDrive today). I will be making them all open and available on GitHub. I'm consolidating their controls (button layout and default behaviours), so they all feel more or less uniform in terms of user experience. It's good to have both options, depending on what people like, and in the event that one side should falter for a particular device/emulation.

And the RetroArch project has always been a great resource, and always will be.

[salvacam]

Better to have more options.

The big problem with Miyoo's standalone emulators is the difference in interface, it would be nice if they unified a bit.
But it's a lot of work and there are few people who are still doing anything for these consoles.

The advantage of independent emulators is that they have better performance, and it is noticeable in some systems, for example in arcades it is better not to have the Mame cores.

Luckily we have independent emulators and Retroarch, all without any economic cost.
And we can use both at the same time, powkiddy has realized this, and has applied it to his miyoo mini

[Apaczer]

Surely the usuability may depend from personal expenctations of the emulation process. If you value a straightforward experience with a good optimization from the gecko, easy configuration, I would say stick with standalone forks (RA can present some obstacles, especially with configuration files overwriting eachother in the process of setting particural systems/games on your device and the time which have to be put to make it work as intended)

The RetroArch as an frontend presents expanded options beyond what indiviudal core/emulator may offer by itself (eg. integer scaling, video filters, sample rate selection). However main advantage would be integration with libretro's pipeline infrastrucutre, where every emulator update is being compiled by buildbot within matter of hours so the core_development->end_user road has become short as it can ever possibly will.

[jSTE0]

I've been trying to find out why RetroArch is quite a bit slower than standalone emulators. One that I've noticed is the audio resampler defaults to "nearest" (which is default on the RS-90 too, being a slow platform as well) but it isn't part of the build so I've submitted libretro/RetroArch#13694 to fix that.
For SNES, I got the 2002 core (based on PocketSNES/snes9x-1.39) building, submitted as libretro/snes9x2002#50. The ASM core is faster than the C core, which in turn is faster than the 2005 core. Still not as fast as the standalone snes9x4d though.
I notice that the audio sampling rate makes a significant difference for SNES, it's fastest (as in least choppy) when left at the default 32730 (which you can't select once you change it as the closest you can get is 32700). I think the issue is the resampler, "nearest" would be the fastest but it still uses floating point, which is slow on the FPU-less CPU.
Even so, with the sound disabled it's still slower at SNES than snes9x4d so I'm not sure where the next bottleneck is.

[jSTE0]

The PRs have been merged upstream and the snes9x2002 core is available in the nightly build. The version number of RetroArch has also just been bumped in git so it looks like a new release is imminent. I still have an outstanding PR for snes9x2005 libretro/snes9x2005#93 that needs to be reviewed.
As for PicoDrive, the libretro core is actually using the C implementation as the Arm asm implementation, including the SH-2 dynarec, is disabled. I tried re-enabling it but it failed during compilation as the generated asm for Cyclone (the 68k core) uses ARMv6 instructions. Probably something not set correctly in the build flags, as it works correctly in the standalone version, I'll keep investigating.

[Apaczer]

@jSTE0 that awesome! We have tested snes9x2002 core while back ago, but it had some image rendering issues (which has been fixed now!) and did not perform better than 2005 version (which again it somehow does now). You've said that "nearest" resampler should be faster, but I saw dropdown in performance (compering to earlier revision), so maybe that's why it was commented out? The "sinc" runs better here, so I switched back to it.
Waiting for that PR to be merged to see some real improvement on SNES!

[jSTE0]

@Apaczer You tagged the wrong user, that's a zero at the end of my username :) I actually built the standard C version first and did come across some rendering issues, some games had an extra "overlay" rendered on top, otherwise had non-visible menus. That went away when I enabled the asm version so I guess the two implementations have drifted apart.
For the "nearest" resampler, the commenting out appears to have been an oversight, at least from my interpretation of the reviewer's comment in the PR. I'm just assuming it's the fastest as it's the default on this and the RS-90 (which has a JZ4725B MIPS32r1 at 384MHz), which are the among the slowest platforms supported by RetroArch. I took a quick glance at the code and it's shorter and doesn't appear to be doing as many operations as the sinc or cc resamplers.

[Apaczer]

yikes, my bad! Sorry I'm doing some back and forth testing now and may not see big difference afterall between nearest and sinc (might need to see how it perform with others cores) but bumping up to 32730 (from recomended 22000 Hz) was definetly what made things go slower.

[jSTE0]

Hmm... I was interpreting slow/fastness wrt to sample rate based on the choppiness but it appears a higher sample rate leads to each chunk of audio being longer in duration. If I drop it to 16kHz it sounds very choppy indeed but it's hard to tell if it's running faster or slower overall as the fps counter seems to bear no relation to the rendering of the graphics and I didn't test for long.

[Apaczer]

Yes I believe the retroarch frontend has a lot less overhead than most of people would think, especially if you think of rgui menu interface (which is very well optimized for those low-end devices, just check the official support list). There are stripped down revisions of retroarch's frontends ready to be ported, but from my knowledge they only simplify things (for ease of use, or for test purpouses) and you can check them here: https://docs.libretro.com/development/frontends/ + another one here: https://github.com/soarqin/sdlretro
The interesting one is picoarch frontend which was written (ported?) by @neonloop for Trimui A66 (F1C200S SOC - same arm926ej-s CPU, faster RAM). He made collection of patches to get some cores running on that hardware with good perform (https://git.crowdedwood.com/picoarch/tree/patches) and even implemented these to official repos for others to use in RA.

[neonloop]

The integer nearest resampler looks useful, do you have plans to submit it upstream?

I have not thought about it -- would it be useful? I expected the retroarch version to be similar, but have not looked at the code.

I notice your snes9x2005 fork has an ARMv5 dynarec, how well does it work?

I might be the only person to try it 😃 It helps when CPU is heavily used. It does not help much for Mode 7 or special chip games, or when games use PPU heavily. More work is needed. It is more comparable to 2002 for many games I've tried. I hope to upstream it, but it needs much more testing

I have compiled picoarch for Miyoo but it does not work for me it gives me an error when trying to open two files

Those errors are normal, they come from libpicofe. First problem I can think of, picoarch needs at least one core in its directory

[jSTE0]

I have not thought about it -- would it be useful? I expected the retroarch version to be similar, but have not looked at the code.

I think so, if only to remove the use of software FPU emulation. I haven't profiled it though.

I might be the only person to try it 😃 It helps when CPU is heavily used. It does not help much for Mode 7 or special chip games, or when games use PPU heavily. More work is needed. It is more comparable to 2002 for many games I've tried. I hope to upstream it, but it needs much more testing

Thank you for trying 👍 . I gave it a quick test and it gave similar results, speed similar to 2002 except for Mode 7 games. Maybe it should be applied to 2002 to make that even faster 😄

[neonloop]

I think so, if only to remove the use of software FPU emulation.

Maybe I will try it. It has been difficult submitting changes upstream, since I don't have low-power device that runs RetroArch, I have been happy with only trimui and picoarch. It means other people will have to test, and debugging problems will be difficult. I still hope to upstream most changes, since maintaining patches separately is also difficult.

Maybe it should be applied to 2002 to make that even faster

It was considered 😃 I like 2005 much more, and hoped I could make it fast enough, possibly port to 2002 after.

[salvacam]

I have compiled picoarch for Miyoo but it does not work for me it gives me an error when trying to open two files

Those errors are normal, they come from libpicofe. First problem I can think of, picoarch needs at least one core in its directory

I have picoarch compiled for Miyoo, not all picoarch cores. A core didn't compile for me, I don't remember which one.

I still have to adjust the controls for Miyoo and will share the Picoarch executable so I can test it.

But now I have little time for personal reasons.
The only thing I have done is indicate the path of the compiler.

[jSTE0]

Forgot to update this thread. It turns out an integer audio resampler won't help RetroArch as its audio pipeline uses floating-point when flushing audio to the device. In audio_driver_flush() it first converts the int16_t samples to float, runs the DSP filter, resamples, mixes, then submits it to the audio driver. If the audio driver doesn't support floats (like SDL audio, or even ALSA if the device doesn't support it, though it does on Miyoo) it converts it back to int16_t.
So to maintain a purely integer audio pipeline a different front-end, like picoarch, is needed.

[Apaczer]

I might got to the bottom of the main topic (mostly in favor of the standalone). Magic word would be PGO (Profile-Guided Optimization), which has been done for many emulators: FCEUX, GpSp, PCSXReARMed,
Snes9x4d … and possibly others.

PGO allows the compiler to reorganize heavily used code together so it can have higher chances of being in cache, and it switches branches so that the branch often used is always in the fast path. It helps with memory relocation - tells the compiler what should be stored in plain code (read parts) and what in cached memory.

It would be hard (if even possible) to implement these profiled optimizations to RetroArch cores, as the stress (to generate *.gcda files) needs to be done on real environement (platform) before compiling AFAIK. Adding to that automated nightly builds, I don't think the RetroArch team will ever implement those.

Here is an example of such profiling:
scooterpsu/pocketgo@5031e14#diff-aba6ef43f0de23c6c1be6e0984e7e237

I've based my PGO test builds of that commit, and I'll admit that benefits are worth the effort!

Instructions:

• set PROFILE to YES,
• compile
• run the emulator for a few minutes (look for intensive game parts)
• dump the .gcda files dropped in /mnt/profile and copy them back into your src folder
• set PROFILE to APPLY
• compile & enjoy optimized build!

You might want to consider adding to GCC flags: -Ofast -fno-unroll-loop
Use the interpreter instead of the dynarec for the PGO build, because doing PGO on a dynarec might not show any results (e.g. PCSX)

[jSTE0]

It would be hard (if even possible) to implement these profiled optimizations to RetroArch cores, as the stress (to generate *.gcda files) needs to be done on real environement (platform) before compiling AFAIK.

It should be possible with something like miniretro by davidgfnet (who improved the dynarec in the gpSP core and also extended it to other CPU architectures like MIPS and x86-64). In this case you wouldn't be interested in the video/audio output of the core and to just collect the profile data to submit to the next stage of the build process. Someone who volunteers and does that work essentially becomes part of "the RetroArch team".
(Technically it is already compiled, it just has extra code to collect the profile data)

Use the interpreter instead of the dynarec for the PGO build, because doing PGO on a dynarec might not show any results

There should still be an improvement as the other non-dynarec parts of the emulator would be optimised, just perhaps not to a noticeable enough degree. The key, though, is whether a PGOd non-dynarec build would actually be faster than a regular dynarec build (I suspect not, if the dynarec provides a sufficiently large speed boost).

[Apaczer]

There should still be an improvement as the other non-dynarec parts of the emulator would be optimised, just perhaps not to a noticeable enough degree.

Of course! The PCSXReARMed has been heavily PGOed by @gameblabla using interpreter as workaround for optimizing that code to use dynarec by end-user in final build. Same goes for gpSP as I would assume.

[jSTE0]

Ah, I forgot that the dynarec can be disabled at runtime so the profile gathering run is done with dynarec disabled, then the binary optimised, then normal runs are with dynarec enabled.

[neonloop]

PGO will not help with dynarec generated code, but can still improve speed with dynarec on -- code generation step, compiled block lookup, other parts of dynarec code can see benefit

I think it is best to try both and compare, in general PGO the way application will usually be run