VOGONS

Common searches


Reply 140 of 150, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

Hi almeath,

> The patch is meant to also work with standard (SDL1) DOSBox SVN?

It's bit-rotten since its last update here, but the work has found a home in DOSBox ECE, DOSBox-X, DOSBox Core, and DOSBox Staging.

For SVN, I'd suggest using the latest state of the patch used by ECE - it was last modified here: DOSBox ECE (for Windows & Linux)

> Also, if I am not needing to actually encode any CD audio into the respective formats, are there any baseline benefits to audio playback that are noticeable in standard DOSBox

Exactly; if you're only playing existing GoG (OGG Vorbis) encoded CD-DA tracks or mounting BIN/CUE's, then the extra codecs add no value.

> or is it just the underlying efficiency of the code that is improved?

Right; there was some mild refactoring done, but certainly nothing "make or break" in terms of performance.

Hope that helps!

--
Edit: added DOSBox-X; thanks for the reminder @Wengier!

Last edited by krcroft on 2021-04-08, 01:04. Edited 3 times in total.

Reply 142 of 150, by Wengier

User metadata
Rank Member
Rank
Member
krcroft wrote on 2021-04-04, 15:39:

It's bit-rotten since its last update here, but the work has found a home in ECE and Staging, like you've mentioned.

And it has found a home in DOSBox-X too (of course - thanks to your work). It is already supported by all major forks by now.

almeath:

As you mentioned earlier DOSBox-X performed slower than SVN for your games in macOS, unfortunately. There are many libraries used by DOSBox-X, but I am sure the performance issue has nothing to do with this patch. You can take as many libraries or features from DOSBox ECE or DOSBox-X into your own build as you want to suit your needs.

P.S. The DOSBox-X Team will eventually find out the exact cause for the said performance issue, although this may take some time. Having a goal of implementing emulations in a complete and accurate manner never stops us from trying to improve the performance too, of course. Porting the dynamic_x86 core from SVN to DOSBox-X 0.83.7 was a very good example of such efforts.

Reply 143 of 150, by almeath

User metadata
Rank Member
Rank
Member
Wengier wrote on 2021-04-07, 05:09:

As you mentioned earlier DOSBox-X performed slower than SVN for your games in macOS, unfortunately. There are many libraries used by DOSBox-X, but I am sure the performance issue has nothing to do with this patch. You can take as many libraries or features from DOSBox ECE or DOSBox-X into your own build as you want to suit your needs.

P.S. The DOSBox-X Team will eventually find out the exact cause for the said performance issue, although this may take some time. Having a goal of implementing emulations in a complete and accurate manner never stops us from trying to improve the performance too, of course. Porting the dynamic_x86 core from SVN to DOSBox-X 0.83.7 was a very good example of such efforts.

Thanks, I appreciate all the work you put into the DOSBox-X branch, and I still use it for certain specific purposes. I fall back to SVN when I need the raw speed, and I have also enjoyed progressively working my favorite ECE and X patches into it. Staging has diverted too far from SVN (different coding) which precludes me from incorporating others that I find interesting, such as the extensive improvements to Gravis Ultrasound. On the speed issue, I am really at a loss to explain it, as I have a 9900k system and I highly doubt it gets bogged down in any way, so there must be something specific hiding somewhere in the code. As mentioned on the Github site, I am always happy to help with further testing. Happy to take this up in the DOSBox-X sub-forum as well.

Reply 144 of 150, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie

All the stuff DOSBox-X added to the dynamic_x86 core to "handle page faults" is mostly nothing but a huge slowdown. Nearly all memory accesses performed by that core (dyn_read_byte/write_byte/read_word/write_word) already handle faults correctly and the remaining opcodes that can cause problems (pusha, popa, etc) are still unfixed. My suggestion would be to rip the whole lot out, if there's anything that it does actually fix it can be implemented in a more optimal way.

Reply 145 of 150, by almeath

User metadata
Rank Member
Rank
Member
jmarsh wrote on 2021-04-07, 09:06:

All the stuff DOSBox-X added to the dynamic_x86 core to "handle page faults" is mostly nothing but a huge slowdown. Nearly all memory accesses performed by that core (dyn_read_byte/write_byte/read_word/write_word) already handle faults correctly and the remaining opcodes that can cause problems (pusha, popa, etc) are still unfixed. My suggestion would be to rip the whole lot out, if there's anything that it does actually fix it can be implemented in a more optimal way.

Would that then have a negative impact on Win9x support? I notice that SVN appears fine with Win95 and 98 .. fast and stable in almost all instances, as long as I use the "pentium_slow" CPU.

Reply 146 of 150, by Wengier

User metadata
Rank Member
Rank
Member

The non-recursive page fault handling was added to the dynamic_x86 core in DOSBox-X 0.83.10 by a contributor, and according to his description this makes the dynamic x86 core more friendly with Windows 9x. But there are apparently known issues with this non-recursive page fault handling, and if he sees this I hope he can make further cleanups to the code if possible. I think he did try to make the non-recursive page fault handling optional with a setting, but I will see if there is anything not yet covered, e.g. by disabling such code completely and compare the performance.

Reply 148 of 150, by almeath

User metadata
Rank Member
Rank
Member
Wengier wrote on Today, 07:12:

The non-recursive page fault handling was added to the dynamic_x86 core in DOSBox-X 0.83.10 by a contributor, and according to his description this makes the dynamic x86 core more friendly with Windows 9x. But there are apparently known issues with this non-recursive page fault handling, and if he sees this I hope he can make further cleanups to the code if possible. I think he did try to make the non-recursive page fault handling optional with a setting, but I will see if there is anything not yet covered, e.g. by disabling such code completely and compare the performance.

If these changes were the primary cause of the slow downs I am experiencing vs. SVN, then I would have been seeing more even performance (against SVN) in earlier versions of DOSBox-X. However, I recall that when I performed benchmarks last year, I was already getting a speed reduction of about 25-30%, which must have been long before these page fault changes were introduced. I will have to do some more testing with the toggle on/off to see if that impacts anything in the latest version.

Reply 149 of 150, by hail-to-the-ryzen

User metadata
Rank Member
Rank
Member

Reverting the dynamic_x86 core to current SVN will likely break functionality in the dosbox-x dynrec core. There was also some merging of code between the dynrec and dynamic core (SVN) which may obfuscate future changes to the dynrec core. In any case, any changes or reversions should also be tested against the ne2000 emulation (Win 9x) since that was a problem area for these cpu cores.

For the cases I tested, the speed reduction with the non-recursive page fault handling (dyn_x86) was not >10%. Dosbox-x is intended as a project with experimental features, so it is fairly common that commits are made that break the emulation (see the s3 mmio emulation, for example). Many of the commits are fixes to other fixes, but that is expected with a priority on adding code instead of fully testing a build that is described as stable.

Reply 150 of 150, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie

The point I am making is not that it is unstable, but that it tries to fix something that isn't broken; the dynamic_x86 core uses the *_checked memory access functions which don't trigger inline page faults. If it didn't use them it would have issues when self-modifying code touched the currently running block. Currently that can still happen via DMA since it bypasses the emulated TLB/memory maps.