It struggles I believe at Pentium like speeds, for anything optimized for the Pentium especially.

kolderman wrote on 2020-05-17, 21:08:

It struggles I believe at Pentium like speeds, for anything optimized for the Pentium especially.

Thanks. But I was really asking what specific cpu you think it's comparable to?

Depends on the host CPU and the game you are running. If you have the latest ryzen or Intel then likely roughly a little higher than a P3 1.4ghz which is overkill for most DOS games.

tmelram wrote on 2020-05-17, 21:20:

Thanks. But I was really asking what specific cpu you think it's comparable to?

It depends on your 'cycles' setting in dosbox.conf. Be aware that DosBox's aim is not to emulate any specific CPU but to be compatible with as many games as possible. So you can emulate a very wide range of CPU speeds by adjusting cycles.
With a modern PC/CPU you can easily achieve 100000 cycles in DosBox that is equivalent to 100 MIPS (million instructions per second). This is already Pentium like speed territory. But not exactly any Pentium model. With 100000 cycles you get roughly:
16-bit integer performance -> Pentium 120 (P54C)
32-bit integer performance -> Pentium 120 (P54C)
Pentium optimized performance -> Pentium 100 (P54C)
32-bit floating point performance -> Pentium 450(!) (P54C)
64-bit floating point performance -> Pentium 550(!) (P54C)
(above results are based on AIDA 1.0 for DOS benchmarks)

As you can see DosBox is rather FPU heavy. FPU speed is not very relevant in case of most DOS games but it is e.g. in case of Quake. So contrary to real CPU that is faster/slower depending on used instructions DOSBox achieve the same MIPS regardless of using 16/32 bit ALU or 32/64 bit FPU instructions.

So if you want to achieve a 486DX2-66 like integer performance you should set cycles to about ~35000 but if you want to achieve a 486DX2-66 like floating point performance you should set cycles to only about ~6000.

@Edit:
As DosFreak has written if you set cycles to 'max' with modern hardware you will get way more cycles than 100000 that can be even P2-P3 like integer and Athlon XP like floating point performance.

compiling my apps

my k6-2-500 is way way faster than dosbox on my 4ghz intel i9700k

running openwatcom on linux building the same app takes a couple of seconds...

all running same version/build of openwatcom, building the same apps + libraries.

dosbox on my 4ghz intel cant compete with my amd k6-2+, 500mhz

Sounds like you know where you need to compile your apps then.

Can't give you an exact figure, but the three machines that I use DOSBox on easily outperform a Celeron-1400.

These are a Ryzen 9 3900X @ 4.3GHz, a Haswell i7-4790 @ 4GHz, and an Ivy-E i7-4930K @ 4.6GHz, all running regular DOSBox 0.74 under Win10 v1909.

In Duke Nukem 3D @ 1280x1024, the Celeron-1400 clocks in @ 45 fps running in a 98SE DOS window.
The 4GHz Haswell kicks out around 70 fps, and the two other machines go even faster. Other demanding DOS games like Screamer 2 SVGA and Quake also run smooth as butter under DOSBox. I think even a cheap little Surface Go should run circles around a 486 or Pentium. 😜

if you use games as examples, then DOSBox emulated VGA/VBE LFB on modern PCs simply destroys anything real DOS with VGA/VBE on PCI/AGP. High-speed / multi-channels DDR3/4 memory on modern PCs with over 4GHz of CPU is faster than anything on PCI/AGP from the past 10 years or so.

If you simply consider CPU computation workload, then I use the rule of 10X for dynamic recompilers implementation, ie. the dynamic recompiler on a 1GHz CPU would be roughly equivalent to a 100MHz real CPU. DOSBox fits the rule pretty well with "core=dynamic" and "cycles=max 105%" using the dynamic-x86 core.

some data is there
DOSBox 0.74 CPU Benchmark
https://www.dosbox.com/wiki/Performance

It's an approximation which supposes a similar enough code.
Doom and Speedtst performance should be useful for most games. Quake is more useful for late 3D games.

BloodyCactus wrote on 2020-05-17, 23:23:

compiling my apps my k6-2-500 is way way faster than dosbox on my 4ghz intel i9700k running openwatcom on linux building the sam […]
Show full quote

compiling my apps
my k6-2-500 is way way faster than dosbox on my 4ghz intel i9700k
running openwatcom on linux building the same app takes a couple of seconds...
all running same version/build of openwatcom, building the same apps + libraries.
dosbox on my 4ghz intel cant compete with my amd k6-2+, 500mhz

I actually think that this is unlikely. If you use DOSBox on Linux and run OpenWatcom from it, then it should be about the same or faster than K6-2 500MHz. I guess you probably did not have your DOSBox using dynamic-x86. If you happen to use dynarec, then that CPU core does not fit the rule of 10X.

With the same rule of 10X, pure CPU performance should be equivalent or advantage on the DOSBox because of Intel i9 host CPU while the K6-2 would suffer a small deficit due to IPC from the same rule of 10X in the comparison. If you compare AMD host CPU and Intel real CPU, the same deficit due to IPC would apply either way, but AMD Zen/Zen2 cores had caught up Intel on IPC. Other than pure CPU performance, everything else is significantly faster on DOSBox, storage access, memory throughput, unless you seriously cripple the Intel i9 host or you have the K6-2 on steroid.

Falcosoft wrote on 2020-05-17, 22:26:

It depends on your 'cycles' setting in dosbox.conf. Be aware that DosBox's aim is not to emulate any specific CPU but to be com […]
Show full quote

tmelram wrote on 2020-05-17, 21:20:

Thanks. But I was really asking what specific cpu you think it's comparable to?

It depends on your 'cycles' setting in dosbox.conf. Be aware that DosBox's aim is not to emulate any specific CPU but to be compatible with as many games as possible. So you can emulate a very wide range of CPU speeds by adjusting cycles.
With a modern PC/CPU you can easily achieve 100000 cycles in DosBox that is equivalent to 100 MIPS (million instructions per second). This is already Pentium like speed territory. But not exactly any Pentium model. With 100000 cycles you get roughly:
16-bit integer performance -> Pentium 120 (P54C)
32-bit integer performance -> Pentium 120 (P54C)
Pentium optimized performance -> Pentium 100 (P54C)
32-bit floating point performance -> Pentium 450(!) (P54C)
64-bit floating point performance -> Pentium 550(!) (P54C)
(above results are based on AIDA 1.0 for DOS benchmarks)

As you can see DosBox is rather FPU heavy. FPU speed is not very relevant in case of most DOS games but it is e.g. in case of Quake. So contrary to real CPU that is faster/slower depending on used instructions DOSBox achieve the same MIPS regardless of using 16/32 bit ALU or 32/64 bit FPU instructions.

So if you want to achieve a 486DX2-66 like integer performance you should set cycles to about ~35000 but if you want to achieve a 486DX2-66 like floating point performance you should set cycles to only about ~6000.

@Edit:
As DosFreak has written if you set cycles to 'max' with modern hardware you will get way more cycles than 100000 that can be even P2-P3 like integer and Athlon XP like floating point performance.

If it helps, I have an i5 3470. Do you know how "dynamic" mode affects this?

It seems it isn’t only the CPU emulation that determines the performance of DOSBox. Some VGA operations seem to be much quicker than a real system. For example, the TOPBENCH video score is a few micro seconds, way less than any real video card I have can do. Also DOOM seems to run very fast for the CPU it should emulate, same with the graphics analyzer of Open Cubic Player in hi-res mode. This can skew your expectations of performance quite a bit.

If you want to measure and compare the 3d gaming performance of your own DosBox setup, I can highly recommend pcpbench (PC Player Benchmark), which renders a little 3D flyby scene and compares your result to some common 486/Pentium machines.

As far as I understand a benchmark like this does not yield a totally reliable result in DosBox since the same cycles setting can have different effects on different games (explanation see above), but personally I always found pcpbench to be a good enough approximation, at least as far as early Pentium era 3D games are concerned.

You can it get together with some other benchmarks here: VOGONS Benchmark archive?

digistorm wrote on 2020-05-25, 13:30:

It seems it isn’t only the CPU emulation that determines the performance of DOSBox. Some VGA operations seem to be much quicker than a real system. For example, the TOPBENCH video score is a few micro seconds, way less than any real video card I have can do. Also DOOM seems to run very fast for the CPU it should emulate, same with the graphics analyzer of Open Cubic Player in hi-res mode. This can skew your expectations of performance quite a bit.

Yes, and I think this can cause problems in a few games; they run too well. I don't have old hardware to test, but I've ran into issues in games such as Syndicate Wars where the cycles settings have to be quite high to let 3D parts of the game run decently, but that causes the menus to animate far too quickly. Cycles have to be reduced to level where the game is unplayable to tame the menu speeds. I don't remember this happening on my PC at the time, and it can be solved in PCem by selecting a slower video card speed.

I've got half a suspicion that NBA Jam TE's problems might be related too.

Silanda wrote on 2020-05-30, 07:15:

I've got half a suspicion that NBA Jam TE's problems might be related too.

If you refer to flickering at higher cycles, that issue should be resolved in SVN.

Silanda wrote on 2020-05-30, 07:15:

digistorm wrote on 2020-05-25, 13:30:

It seems it isn’t only the CPU emulation that determines the performance of DOSBox. Some VGA operations seem to be much quicker than a real system. For example, the TOPBENCH video score is a few micro seconds, way less than any real video card I have can do. Also DOOM seems to run very fast for the CPU it should emulate, same with the graphics analyzer of Open Cubic Player in hi-res mode. This can skew your expectations of performance quite a bit.

Yes, and I think this can cause problems in a few games; they run too well. I don't have old hardware to test, but I've ran into issues in games such as Syndicate Wars where the cycles settings have to be quite high to let 3D parts of the game run decently, but that causes the menus to animate far too quickly. Cycles have to be reduced to level where the game is unplayable to tame the menu speeds. I don't remember this happening on my PC at the time, and it can be solved in PCem by selecting a slower video card speed.

I've got half a suspicion that NBA Jam TE's problems might be related too.

It would be nice if different parts could have the speed adjusted and not just overall. I think multithreading would help as well. I suspect that the multithreading could be done with no locks or almost no locks.

Main thread would be the CPU and probably file I/O and it would also pass things such as video and sound to other threads. Any stuff that needed to be accessed by the main thread that other threads work on would be put into global variables and arrays.
I think it really should be doable and I have already programmed a lock free super multithreaded primes number generator - up to 2^32(-1) threads - (only lock is a spin lock that is in the main thread that waits for all the worker threads to complete).

It sure would be interesting to try out my theory.

ripsaw8080 wrote on 2020-05-30, 07:40:

Silanda wrote on 2020-05-30, 07:15:

I've got half a suspicion that NBA Jam TE's problems might be related too.

If you refer to flickering at higher cycles, that issue should be resolved in SVN.

Cool! I'll admit that I haven't tried playing it in ages.