[Performance Discussion] Libretro PCE is slower than Mednafen PCE about beetle-pce-libretro

My opinions are:

• Libretro CPU overclocking method. That should eat some cycles as its done very heavily. If it was switched to Mesen-like PPU overclocking, maybe it'd help recover some speed.

• Doesn't standalone have SIMD / AVX support for the resampler? I'm thinking Libretro core does not enable?

• Retroarch shaders are off? The ultra-wide base textures are huge! (2048x2048)

[inactive123]

Important to bear in mind that RetroArch does not use frameskipping while fast forwarding, but just disables audio and video sync instead. I am not sure how Mednafen's fastforwarding works (somebody would have to look at the SDL implementation), but it's possible it could be accomplished through frameskip. Either way, it should be taken into consideration that we cannot compare FPS results 1:1 because of this.

That being said, I do not discount the fact that possibilities might exist for things to become more performant on the libretro core side here.

[negativeExponent]

let me remind, that this is not a "comparison" as in a debate purposes. just intended to make some more optimizations to be equal if not better than upstream. And to reply to the frameskip thing, frameskip can also be disabled in mednafen. i think its also in the screenshots.

[inactive123]

Yeah I understand its intent and I appreciate it.

…

On Tue, 22 Sep 2020, 06:25 negativeExponent, ***@***.***> wrote: let me remind, that this is not a "comparison" as in a debate purposes. just intended to make some more optimizations to be equal or not better on upstream. and to reply to the frameskip thing, frameskip can also be disabled in mednafen. i think its also in the screenshots. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#11 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIGQSQTSN5HKUKKGAUIUJLSHARLVANCNFSM4RVH3NZA> .

[Tatsuya79]

I compared the core with stand-alone a while ago and reached the same conclusion as negativeExponent; that the core is lagging behind it perf wise. (it should be 80% faster looking at notes I took)

I tried removing some code in the internal video part in case anything costly would have been added in a timing sensible place, but I found nothing relevant.

I wonder if it's just a muti-threading thing we don't do here?

[mrjschulte]

Perhaps there are optimizations we do when compiling down that the original doesn't have. I've seen how picky Mednafen is with some optimization flags and perhaps forcing -O3 has some adverse effects. Needs more investigative work for sure.

[negativeExponent]

wonder whats going on here:

looks like horizontal display registers gets way out of bounds for a frame or two when last scanline is increased passed 239

[mrjschulte]

Perhaps this is related to the "fixes" made in the vce to allow for more scanlines but I can't see how:
d05b6cc

[negativeExponent]

normally, you should be able to show all 243 visible lines (regardless if they are just data, or extra background,overscans) and that is fine. In this case though, its probably switching late. it might even make sense to just make these 243 and just let initial/last scanline options to handle how many scanlines needs to be drawn and to set the height. I haven't looked at the core closely though

when the core gets to a good performance level, make it available for all if not most platform libretro supports, then this can be a defacto PCE core and retire the supergrafx one. (the pce_fast still need to be maintained for performance reasons). But as of now, ill stay with pce_fast/supergrafx