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?

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

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

I haven't been building the 0.74-3 exe, just testing against the official download.

Out of interest, I performed a 32-bit MinGW build of SVN though as I hadn't tested that in a while. I didn't see anything untoward in the configure output but performance of this executable is better than I used to get: 4550000 parrots, 1687.1 XT. Not as fast as a VS build, but significantly faster than stock 0.74-3 in Speedtst (3033333 parrots, 1124.7 XT). VS build is still 11% faster though. Maybe something has changed because I seem to recall getting performance similar to stock with my SVN builds in the past.

To be fair, the performance delta between 32-bit builds in Quake at 320x200 doesn't seem as dramatic as that shown in the Speedtst scores. 0.74-3 gets ~212fps, 32-bit MinGW SVN build gets ~220fps, 32-bit VS build gets ~245. The VS build is about 15% faster than 0.74-3 and is 11% faster than the MinGW SVN build (same as Speedtst result). No reason to use any of these over a 64-bit build though, as that's significantly faster than all of them.

EDIT: Changed MinGW 32-bit result as the score I previously got was a low outlier.

I ran this on my i9-9900KS @ 5.2 GHz and the framerate is actually LOWER (about 74 FPS) than my i7-7700K 5 GHz runs. Weird. I got 83 FPS in 800x600 in timedemo 1 in fullscreen mode, though.

MrEWhite wrote on 2020-02-22, 02:21:

I ran this on my i9-9900KS @ 5.2 GHz and the framerate is actually LOWER (about 74 FPS) than my i7-7700K 5 GHz runs. Weird. I got 83 FPS in 800x600 in timedemo 1 in fullscreen mode, though.

2/76 = ~3% is in borders of measurement accuracy, according to what I saw. There was no significant per Hz improvement between those CPU series and the clocks 5.0 and 5.2 are very close. In totally identical environment and making several tests runs you are expected to notice 2-4% average improvement (for fine difference of CPUs is better to use 320x200 mode).
For human perception up 10% fps difference is doubtful to be noticable.

Silanda wrote on 2020-02-19, 22:34:

To be fair, the performance delta between 32-bit builds in Quake at 320x200 doesn't seem as dramatic as that shown in the Speedtst scores. 0.74-3 gets ~212fps, 32-bit MinGW SVN build gets ~220fps, 32-bit VS build gets ~245. The VS build is about 15% faster than 0.74-3 and is 11% faster than the MinGW SVN build (same as Speedtst result). No reason to use any of these over a 64-bit build though, as that's significantly faster than all of them.

According to jmarsh, official 64-bit build has no dynamic core. So this variant has noticed ones or is tested for compatibility issues still.
When 64-bit dynamic mode will be inputed in the official release, it may become useful to add 64-bit version of DOSBox in the benchmark theme.

In the 1st theme's message I've added the testing procedure with bat files.
It would be interesting to see a direct comparision between different DOSBox builds of today.
official 0.74 (32-bit), official 0.74-3 (32-bit), SVN MinGW (32-bit), SVN MinGW (64-bit), SVN VS (32-bit), SVN VS (64-bit)
6 numbers of results. The used SVN version should be said.
Emulator's files (.exe and .dll) should be changed between the testing runs.
The comparision may be limited to Quake 320x200 dynamic core testing (with single demo1 run). It needs to place '#' before the line "quake.exe +vid_mode 13 +timedemo demo1" in quake_test.conf. The testing is run by tests2.bat, press "Space", fps is written, build's files are changed and the testing is repeated.
In case you'll create those 4 SVN builds, it would be useful to place them on a filehosting like mediafire, so other CPUs could be tested with them also. For example, to check what happens on modern Intel CPUs.

Official (0.74-3 and older) 64-bit builds have a dynamic core, but it's not the 64-bit dynamic_x86 core.

jmarsh wrote on 2020-03-01, 02:05:

Official (0.74-3 and older) 64-bit builds have a dynamic core, but it's not the 64-bit dynamic_x86 core.

then those are not 64-bit completely builds 😀