Execution rate at DOS prompt, menus, etc.

[ecksemmess]

Finally getting a chance to play around with PCem 13.1, and sure enough, it looks like some of those recent dynarec tweaks have MASSIVELY improved execution rates at the DOS prompt, game menus, and other idle-loop areas that previously brought the emulator to its knees. These loops do still cause noticeable slowdown so there's definitely some room for improvement, but the difference from before is absolutely incredible, night and day. This is actually a really huge deal! In one fell swoop, the last major remaining immersion-killer has nearly been eliminated. No more stuttering game theme music! Thanks so much to Sarah and whoever else made this happen! There was remarkably little fanfare about it...

If anyone knows of anything that's still tripping up the recompiler, please share here. Everything I've tested is running great, with only one peculiar exception so far: the idle loop when no boot device is found on the Intel Advanced/EV still makes the recompiler struggle a lot. What could that loop be doing that would cause so much more block churn than, say, the DOS prompt, BIOS screens, etc.? I'm guessing it has to do with the fact that it's not waiting for or accepting any input, unlike those others? Not that it really matters in practice, obviously, but perhaps it could be a useful indicator of where the remaining weak points are.

[leilei]

So far the only unusual recompiler choking i've seen on v13.1 is with Ms. PacPC (JROK's excellent DOS Ms. Pacman recreation). Oddly PacPC is not affected.

[ecksemmess]

Just noticed another major recompiler choker: the "it's now safe to turn off your computer" screen after shutting down Win9x. The level of slowdown is exactly the same as the "no boot device" idle loop I mentioned above, suggesting that they may both be caused by the same recompiler weak point. Once again, I have a feeling it's not a coincidence that both of these occur at "dead end" points where no further system activity or input is expected until the next reboot. Obviously not much of a practical concern, but possibly worth looking into.

Separate from that, I've also discovered a bug that seems to occur reliably with the "it's now safe to turn off your computer" screen: PCem seems to completely stop redrawing the emulated display as soon as that screen comes up. Switching to/from fullscreen, resizing the window, etc., all make this awkwardly obvious. Again, it's not much of a hindrance in practice, but this behavior can't be intentional and must be indicative of a more general emulator issue. If there's any difficulty in reproducing it, let me know and I'll provide all potentially relevant PCem settings.

[leilei]

That lack of refresh is intentional. If you don't like that, you can use the OpenGL 3.0 renderer where all refresh is forced (allowing shaders to constantly work etc)

[SarahWalker]

Not to be rude, but could you wait until I've done the recompiler rework before making more suggestions? I am aware of the problems with it, and already know that the solutions are not simple, which is why I'm going to spend most of the year reworking it!

The Win9x shutdown screen has the same performance behaviour as sitting at the DOS prompt because that's basically what it is. The screen not updating when idle is intentional as leilei says (it's an optimisation), but it should really get updated still when resizing/minimising/maximising/whatever the emulation window - that one is a bug.

[ecksemmess]

No problem at all, I'll hold off on digging further into this until the recompiler rework is done. (Just as a point of order, the observation I was trying to make was that the Win9x shutdown screen does not have anything even close to the same performance behavior as the DOS prompt idle loop, which I found interesting, but it's probably not worth discussing that further right now as I'm sure you've got it all fully under control.) And as far as the screen not updating--yes, it was specifically the resizing/minimizing/etc. issue I was talking about. It does seem worth fixing that at some point for situations where, e.g., a non-updating screen might be displaying important diagnostic info which could easily be lost and unrecoverable upon exiting fullscreen, restoring from a minimized window, etc.

Best of luck with this year's recompiler work, by the way! Exciting stuff, I'm greatly looking forward to it.