Dosbox emulated performance vs. real world computers (laptops)

[dodleh]

Code of Conduct & Contributing Guidelines

• I agree to follow the code of conduct and the contributing guidelines.

Have you checked that no other similar feature request(s) already exists?

• I have searched and didn't find any similar issues.

Is your feature request related to a problem? Please describe.

Dosbox could be improved to better mimic real world systems. This will free up some resources during emulation as Dosbox is too fast in some respects (graphics), while CPU emulation is already costly.

What you want

To help developers have a better perspective on real world systems and help with testing in similar circumstances.

Describe alternatives you've considered

Configuring DosBox in number of cycles/second and other parameters offer only a partial solution that does not cover graphics emulation (VGA and SVGA, mostly).

Additional context

There should be a way of limiting GPU performance with some general guidelines that could work such as a suggested parameter that could limit the number of pixels/second output by the GPU that could cover 2D operations, as a 3D operations/second set of parameters is even more difficult to imagine, at the moment (there are so many parameters that translate in operations with varying degree of performance in 3D scene setup as well as the separate issue of rendering).

I hope the text below is a good conversation starter. ;)

[dodleh]

Dosbox performance vs Real World performance in benchmarks and games 2021.xlsx

[Wengier]

I agree that the CPU cycles are only a partial solution to the problem you stated. DOSBox-X is designed to be highly configurable so I think it is indeed a desired function. You made a nice chart by the way.

[dodleh]

The chart hopefully offers a very good reference on how real world systems behave and all tests have been carried by me on my system collection. Thank you.

The most important result, in my opinion, that shows a clear departure in terms of authenticity is the one on Torque, in Windows 3.x. I have to say that in some DOS games that are also more videocard sensitive (such as QUAKE, if I remember right), the same issue is felt. Even older games such as Lotus, feel a bit smoother than on a real system, which points at a graphical performance that is not well simulated.

Another reason for the utility of the above chart is that it paints a reasonable expectation goal for emulation. As I see it, if emulation resources are handled better, a 300-400 MHz CPU and Voodoo 3 card can be reasonably expected to work on modern systems and around a 166MHz for older systems such as Core 2 Duo CPUs, which would be fantastic.

The only small issue that I have right now in documenting proper performance comparisons is that micro-stuttering and input delays are almost impossible to represent and this is one important long-term goal of emulation.

Later edit: I also noticed that Ignition (the Windows version, in software rendering mode) is very picky about emulation fluency and especially graphics. On a real system you can notice a specific gaming pace and framerate consistency. On emulated systems it is very hard to achieve that. Either the games runs choppy (86Box, PCEM) or it runs much more fluent than in reality (DosBox-X). This happens on similarly fast emulated systems with roughly the same configuration, under Windows 95 OSR2. Running the game with FRAPS and observing FPS in specific spots on a race shows some very interesting values.

[Torinde]

Would be nice DOSbox-X to become one of the benchmarking tools utilized by sites such as Anandtech.com - to populate their Bench or just to allow us to populate a table like that above (or here) and to provide answers such as "To emulate Pentium Pro 200MHz you need one core of Ryzen 2GHz". I think if DOSbox-X developers approach some of the CPU benchmarking sites they will gladly join to devise automation, logging, etc. features and procedures that would make the process smooth.

Per what I understood:

• CPU emulation is a single-thread algorithm, unsuitable for splitting, and further speed increases can come either from better host CPU (frequency and IPC) or virtualization instead of emulation
• Video emulation (Glide, 2D as well?) can benefit from multiple threads/cores. Unclear if DOSbox-X Glide/2D emulations currently have multithreaded code? Multithreading patch for 3Dfx Voodoo emulation? #5206
• remaining activities are not so computation-intensive

Since modern CPUs are multi-core, for simplification we can assume one core is dedicated to CPU emulation with the remaining cores taking care of Video emulation and any other minor tasks. Thus CPU and Video emulation can be benchmarked in isolation, e.g.:

• single thread benchmark: CPU emulation - "To emulate Pentium Pro 200MHz you need one core of Ryzen 2GHz"
• multi-thread benchmark: Video emulation - "To emulate Voodoo 2 you need 3 cores of Ryzen 2.5GHz"
• thus if I want Pentium Pro 200MHz with Voodoo2, then a 4 core Ryzen 2.5GHz is sufficient

Will larger CPU cache help with CPU emulation? Ryzen 5800X3D 96MB (32MB CCX+64MB extra), Threadripper 256MB (8x 32MB CCX)?

Another question, maybe @joncampbell123 - how does the conclusion that CPU emulation is unsuitable for splitting squares with the x86 emulation performance by Apple and Microsoft in their OS editions running on ARM? Don't they provide much closer-to-native performance than DOSbox-X? Can some code be leveraged from the Intel Itanium IA-32_Execution_Layer (LGPL) (LGPL) or the Itanium 2 emulator?

[Torinde]

Idea for multi-threaded CPU emulation:

conceptual model mimicking of real hardware in software dynamic re-compiler designs can have 1 thread emitting and chaining translated cacheblocks while another performing the executions and updating architectural states. This is an over-simplified 2-thread model. A slightly more advanced model can spawn a new thread on branch instructions emitting and chaining translated cacheblocks for both paths in parallel. It is OK to throw away non-taken branch. In fact, Intel Itanium does the same in hardware to avoid stalling the pipelines.
...
approach quite similar to Transmeta "run-ahead" concept of "Code-Morphing".