Is there a good method for testing how many fixed cycles a cpu can handle? Currently I'm doing Quake benchmarks at cycles=max, then I test with fixed cycles and try to approach that average fps number. I usually knock a few thousand cycles off my estimate because I think Quake uses protected mode and fairs better than realmode games. Doom is tough to use as a benchmark because you have to look for dropped frames/audio because it will continue to report higher realtics even tho it's choppy. Also I dont like using the pure CPU benchmarks (ie Speedtest) because dosbox isnt doing any graphics or audio emulator while its trying to max out the cpu.

Like my current estimate for 1.6ghz Atom cpus that were popular in cheap netbooks and thin clients is ~38000 cycles. Basically id like to relate all this data back to a fixed number of dosbox cpu cycles. Anyone have a better system?

BinaryDemon wrote:

Is there a good method for testing how many fixed cycles a cpu can handle?

In different games the emulation speed differs. There is no accurate answer.
For practical purposes it's enough to set cycles near aproximated for the needed machines or max.

Besides games and benchmarks it's possibly to use ykhwong's version (1) which reports a number of cycles with max setting.

> Like my current estimate for 1.6ghz Atom cpus that were popular in cheap netbooks and thin clients is ~38000 cycles.

Would be interesting to add results of this CPU gotten by the test procedure.

Qbix wrote:

Is there a huge difference ? The algorithm that determines the max speed was changed a lot between 0.74 and 0.74-2 and the 64 recompiler got a lot of changes.
However on win32 the only change is the max cycles algorithm.

I recall dosbox is configured the way that even cycles max 105% doesn't use 100% of a core but only 97% or something similar. Would it be possible to unleash all 100% on multi core cpus and leave the way it is for single core (and maybe dual core) ones only? The way you can set cycles max 108% on 4 (and more) core ones?

robertmo wrote:

Would it be possible to unleash all 100%

There is way by fixed number of cycles. Which you may also tune manually during gaming. You'll notice stuttering in case cycles are too high. Then reduce cycles until the game will go good - that should be 100%. For every game, scene, game's and emulator's settings - appropriate cycles may differ. Ykhwong's version may show cycles in numbers when you use max setting.
You should not notice fps changes until 10-15%. So 95% and 100% cycles will look for you as same, except when cycles are too high due to background processes and you get stuttering.

I was writing about the internal limit in dosbox that is configured to never use 100% of your core to prevent stuttering.
But I figured out that my idea was not good cause it is not only other programs causing stuttering, but also dosbox itself when it gets more cpu hungry with same number of cycles.

robertmo wrote:

I was writing about the internal limit in dosbox that is configured to never use 100% of your core to prevent stuttering.

And there is no limit when you set cycles' as concrete number manually.

Ryzen R5 3600 @ ~ 4.15ghz
16GB DDR 4 3200 CAS 16
Windows 10 Pro x64

Speedsys normal: 625430 parrots, 231.9 XT
Speedsys dynamc: 2800000 parrots, 1038.2 XT

Doom normal: 79.6fps/938 realtics
Doom dynamic: 290.6fps/257 realtics

Quake_SW 800x600: 59.2, 58.9, 58.9
Quake_SW 320x200: 183.6, 183.9, 183.3

A note on precision boost 2.0 - it oscillates clock speed between 4.05 and 4.2ghz constantly. 4.15ghz is pretty close to the average. How long and how often it reaches top speed depends on cooling and the power limits set in the bios. I have the power limits set to max, which means the motherboard determines the power limits. Different board could set a different limit, and better cooling lowers power consumption at the same voltage and clock speed, ect. I have a really good air cooler (Noctua NH-D15) and a decent board (ASRock B450 Pro4), so my setup could be + / - 5% compared to someone else, but probably represents the upper range for this particular chip.

Hi mothergoose729, I noticed that Ryzens have some way worse performance in Dosbox than intel on same frequency. Just could you make a quake test while set the CPU affinity for dosbox proccess to only one CPU core? And maybe same with disabled hyperthreading/SMT or how it's called on AMD in SETUP? Maybe as dosbox process is switched from core to core by scheduler it could degrade performance. On my intel i7 I also observer worse/inconsistent performance of single-thread apps while hyperthreading was enabled so I have id disabled by default.

RayeR wrote on 2020-02-18, 17:20:

Hi mothergoose729, I noticed that Ryzens have some way worse performance in Dosbox than intel on same frequency. Just could you make a quake test while set the CPU affinity for dosbox proccess to only one CPU core? And maybe same with disabled hyperthreading/SMT or how it's called on AMD in SETUP? Maybe as dosbox process is switched from core to core by scheduler it could degrade performance. On my intel i7 I also observer worse/inconsistent performance of single-thread apps while hyperthreading was enabled so I have id disabled by default.

Yeah it is interesting. My Ryzen CPU is slightly under performing in these benchmarks. I would expect my results to be maybe 10%-15% higher based on clock speed and relative IPC.

I set my clock speed to a fixed 4.15ghz and disabled hyperthreading. Ran the quake benchmark and got pretty much identical results.

Ryzen can be sensitive to memory bandwidth. A CAS 14 kit and/or memory with higher bandwidth could improve performance by a substantial amount in some benchmarks.

mothergoose729 wrote on 2020-02-18, 03:26:

Ryzen R5 3600 @ ~ 4.15ghz

Thank you.

The improvement per Hz is ~15% compared to Ryzen 2xxx. Now it's close in DOSBox to Intel 4xxx at the same Hz.

> A note on precision boost 2.0 - it oscillates clock speed between 4.05 and 4.2ghz constantly. 4.15ghz is pretty close to the average.

It's close to random performance variations to take as formal 4.2 GHz.

mothergoose729 wrote on 2020-02-19, 03:11:

Ryzen can be sensitive to memory bandwidth.

DOSBox test has low influence from a memory of modern PCs. With lower or higher memory clocks you should get the same results.
You may notice, the previous generation as AMD FX also has lesser performance in DOSBox than Intel CPUs of near time. In single core games (which are not limited by GPU load) you should notice the significant difference too. "Stalker" trilogy is one of single core 3D games where that should be seen. Seems, in some modern games (made for 4-8 threads) first Ryzens had lower performance (at 0.1% fps, for example) than i7 2xxx with same cores+frequency and could became close since Ryzen 2xxx (what can be assumed by DOSBox bench).
There can be 2 reasons: 1) Intel has developed x86 and so has better resources for more advanced architecture, 2) today apps (and mb compilers) are mainly pointed, tested and better optimized for Intel CPUs specifics, as those CPU are more common.

It's not clear, but probably it's possibly to compile some apps (as DOSBox) by other ways to get higher performance on Ryzens.

Yeah it is interesting. AMD IPC compares favorably to intel processors in some benchmarks and not in others. This dosbox benchmark is probably the biggest gap I have seen so far. The Kaby Lake CPU benchmarks are, on average, 12% faster clock-for-clock than Ryzen, and the haswell CPUs, which are usually 10-15% slower than zen 2, perform pretty much the same.

15% more performance over zen+ is right in line with what is to be expected.

I've posted about this in another thread the past, but in my tests my Ryzen 3700x underperforms in 32-bit builds built with MinGW (like the official releases). However, it performs far better with MinGW 64-bit builds or 32-bit builds created with Visual Studio.

My Quake timedemo score at 320x200 is ~283fps using my 64-bit SVN build, ~248fps with a 32-bit Visual Studio build.

FWIW, I've attached my 64-bit Speedtst results as another example.

I score 5870968 parrots, 2176.9 XT with the dynamic core and 887805 parrots, 329.2 XT with normal.

mothergoose729 wrote on 2020-02-19, 17:23:

Yeah it is interesting. AMD IPC compares favorably to intel processors in some benchmarks and not in others.

The example where 1st Ryzens are close in the performance to Sandy Bridge (of same 4/8 and close frequency).

In DOSBox 2nd Ryzens are close to Sandy Bridge, while 1st are expected to be close or a little below on ~7%. There is also a factor of faster DDR4 memory of Ryzens compared to DDR3 of Sandy and where this factor is important, - Ryzens should get higher results due to faster memory. Besides that benchmarks are approximate and correlate not totally.

> This dosbox benchmark is probably the biggest gap I have seen so far.

Also, someone with Sandy and Ryzen 2xxx could run "Stalker" to check the assumption about similar performance in 1-core 3D games of 2000s. For this is better to set DDR4 to 2400 and DDR3 to 1866 to reduce possible memory influence.

Silanda wrote on 2020-02-19, 18:03:

I've posted about this in another thread the past, but in my tests my Ryzen 3700x underperforms in 32-bit builds built with MinGW (like the official releases). However, it performs far better with 64-bit builds or 32-bit builds created with Visual Studio.

VS was assumed to allow better performance of DOSBox than official builds. So 64-bit code may help too, sometimes.
In the aspect of CPU comparision should be noted that same improvement by the said factors may happen on other modern CPUs too.

> My Quake timedemo score at 320x200 is ~283fps using my 64-bit SVN build, ~248fps with a 32-bit Visual Studio build.

1.5x improvement (in Win10 x64) from VS+64bit. fascinating...
the version of Visual Studio and compiling settings mb important too

Would be nice if there was a site which keeps so much faster builds and mb updates them according to newer SVN.
This may help those who runs Voodoo software emulation, for example.

I using the 64-bit version of MinGW through Msys2 (GCC 9.2.0) to compile 64-bit builds, and version 16.4.5 of VS Community 19. 64-bit builds are comparable between VS and MinGW, with MinGW being slightly faster IIRC.

FWIW, attached are my results of Speedtst with a 32-bit VS19 build.

5055556 parrots, 1874.5 XT for dynamic
710938 parrots, 263.6 XT for normal

The normal core's not that much faster than stock (+6% in my tests), but that dynamic score... It's 66% faster than what I'm getting in stock 0.74-3. Even producing executables in VS that explicitly do not use enhanced instruction sets still result in ones with 50%+ dynamic scores in Speedtst when compared to stock. Some extra speed from VS is one thing, but 50%+? Something's going awry here.

Food for thought:

https://hothardware.com/reviews/amd-ryzen-9-3 … shootout?page=2

This review compares Ryzen 3900x with two cores disabled to i9 9900k, with both CPUs locked at 4.0ghz.

Silanda wrote on 2020-02-19, 20:06:

It's 66% faster than what I'm getting in stock 0.74-3.

0.74-3 doesn't have the 64-bit dynamic_x86 core, SVN does.

jmarsh wrote on 2020-02-19, 21:31:

Silanda wrote on 2020-02-19, 20:06:

It's 66% faster than what I'm getting in stock 0.74-3.

0.74-3 doesn't have the 64-bit dynamic_x86 core, SVN does.

I'm comparing 32-bit dynamic there; it's my 32-bit VS build that's 66% faster than 32-bit 0.74-3. The 64-bit build is faster still.

Do you read the output of configure to make sure everything is being detected correctly?