press ctrl-shift-esc
and check in task manager how many cpu percentages dosbox process is using

~7-7.5%, which makes sense if Dosbox is mainly running on a single thread and a Ryzen 7 exposes 16 logical cores. HwInfo's monitoring seems to back that up; approximately 95% utilisation of a single thread, with the workload seeming to be spread between two cores/threads.

I'm not going to test it right now, but I'd be interested to see what happens with SMT turned off. I ran into part of a modern benchmark recently that massively underperformed when it was supposed to be using SMT. In that case the core frequencies hardly moved above idle though.

Disabling SMT does nothing, and locking DOSBox to use only the best physical core of the CPU does nothing either. At best there's a 5 point increase in score, and I was seeing variances between runs of that sort of number anyway.

after turning off threading you should have only 8 cores available in resources monitor
and in task manager dosbox proces should be using about 12,5%

robertmo wrote:

after turning off threading you should have only 8 cores available in resources monitor
and in task manager dosbox proces should be using about 12,5%

When I said it did nothing, I was talking about nothing to DOSBox's performance. It virtually fully loads a single core of the eight.

The only conclusion I've been able to reach is that the 32-bit versions underperform on Ryzen, though I have no idea why. 64-bit builds with the newly fixed dynamic core perform more in line with what I expected and what CPU benchmarks suggested. I'd love to be proven wrong, but I'm not new to this and I haven't found anything to suggest that the 32-bit scores I've given are inaccurate.

I actually held off posting results because they didn't seem right, but I've been unable to find anything wrong and the CPU usage percentages seem correct; in virtually every application, even ones like PCem, the Ryzen kills my old i5 3570k, but not 32-bit builds of DOSbox. The 64-bit results were a pleasant relief.

You can monitor the loading of each thread in the perfmon in Windows 10. QEMU would use up to 4 threads on FX8300.

Found something interesting about my results - my 32-bit Visual Studio builds are much faster. My own builds using MinGW were comparable to 0.74-3, however, this is an SVN build built using VS19:

D1:
Microseconds 1 loop: 2.32
Dhrystones / second: 431267
VAX MIPS rating: 245.46

D2:
Microseconds 1 loop: 2.37
Dhrystones / second: 422164
VAX MIPS rating: 240.28

The only functional difference between it and my MinGW builds is the lack of screenshot support. Got some libpng related compilation errors that I don't have time to look into at the moment.

That is odd. The difference is a lot larger than I would have expected. (mingw32 vs visual studio 32bit build).

might be worth to try also (just the official builds)
0.74 and 0.74-2
https://sourceforge.net/projects/dosbox/files/dosbox/
to possibly narrow down the problem

I've only tested briefly but 0.74 and 0.74-2 have similar performance to 0.74-3: topping out at around 180, so significantly below that of my VS19 builds. Also, enabling screenshot support in the VS builds may have a measurable performance impact, though not a large one.

I'd be interested to try a 64-bit Visual Studio build, but my attempts at building one have resulted in executables that do not work.

Silanda wrote:

I'd be interested to try a 64-bit Visual Studio build, but my attempts at building one have resulted in executables that do not work.

If you're using the config.h found in src/platform/visualc, it needs some fixes for 64-bit. Remove the "#define C_TARGETCPU X86" line, set C_FPU_X86 to 0 and change the internal type definitions (at the bottom) to look like this:

1/* The internal types */
2typedef  unsigned char		Bit8u;
3typedef    signed char		Bit8s;
4typedef unsigned short		Bit16u;
5typedef   signed short		Bit16s;
6typedef  unsigned long		Bit32u;
7typedef    signed long		Bit32s;
8typedef unsigned __int64	Bit64u;
9typedef   signed __int64	Bit64s;
10#ifdef _M_X64
11#define C_TARGETCPU X86_64
12typedef unsigned __int64		Bitu;
13typedef signed __int64			Bits;
14#else // _M_IX86
15#define C_TARGETCPU X86
16typedef unsigned int        Bitu;
17typedef signed int          Bits;
18#endif

Then you should be able to switch between 32/64-bit builds just by changing the platform config in the IDE.

Thanks for that!

Results aren't really worth posting; they're comparable to the 64-bit mingw builds. Slightly slower if anything.

I thought I might post this, as it seems kinda weird.

core=dynamic cycles=max

core=dynamic cycles=3000 (default)

core=dynamic cycles=10000

At "max" syschk just takes forever to get through the video test. The first 3 seconds or so fly by and then it just goes slow enough to see the text scroll.

Have we reached the point yet where DOSBox, running on the most powerful PCs available to the public, can emulate games faster than they can run in real DOS on any machines? Come to think of it, my question implicitly assumes that DOS itself can't natively run on modernish (say from 2010 or 2015) hardware, is that actually the case? Even if the DOS game in question is 16bit, can it run on a 64bit CPU? Are there any DOS versions (MS-DOS, FreeDOS, etc) that are entirely in 32bit (or even 64bit) so they can work fine on a 64bit CPU?

This is why DOSBox is great for idiots like me, it means we don't need to actually know much to get DOS games working well on modern machines 😊

Kerr Avon wrote:

Have we reached the point yet where DOSBox, running on the most powerful PCs available to the public, can emulate games faster than they can run in real DOS on any machines? Come to think of it, my question implicitly assumes that DOS itself can't natively run on modernish (say from 2010 or 2015) hardware, is that actually the case? Even if the DOS game in question is 16bit, can it run on a 64bit CPU? Are there any DOS versions (MS-DOS, FreeDOS, etc) that are entirely in 32bit (or even 64bit) so they can work fine on a 64bit CPU?

This is why DOSBox is great for idiots like me, it means we don't need to actually know much to get DOS games working well on modern machines 😊

Well. That I know. I ran both MS-DOS and Windows 95 on my old PC(about 5-7 years ago). I ran them from a bootable USB formatted with some special tool. The CPU was an AMD K6 or K8 I believe. Ran Windows 7 32-bit(2GB RAM) on it until I found out it could actually run x64 windows as well!

Windows 95 ran on it, but due to lack of video drivers(same for MS-DOS games) and other than PC speaker (no CD-ROM) not much could be done with it. The same would basically apply to MS-DOS games I think? Unless someome found a way to use old 16-bit sound blaster and video card on the modern bus.

So, the CPU, probably most of them(perhaps not stuff like the incompatible ones like those mentioned having problems the last few years(e.g. with Windows XP) with V86 mode(imagine EMM386 crashing). So games using V86 mode might not run. But basic MS-DOS real mode and 80286 software will probably run on most modern CPUs. But probably forget about driver support and non-minimal hardware support. So probably VGA with 80286- games and PC speaker would be all that's possible without emulation.

Kerr Avon wrote:

Come to think of it, my question implicitly assumes that DOS itself can't natively run on modernish (say from 2010 or 2015) hardware, is that actually the case?

No. All current x86 CPU's from Intel/AMD (even the newest ones) are still fully x86 compatible (by definition) so they can still run 16-bit DOS/programs natively. The only problem can be UEFI with no Compatibility Support Module (CSM). If BIOS compatible CSM is missing from firmware then you cannot boot MS-DOS/FreeDos. Such PC's already exist (mainly laptops) but are relatively rare. Modern video cards are also still more or less VGA/VESA compatible so the biggest problem considering DOS gaming on modern systems is sound.

Even if the DOS game in question is 16bit, can it run on a 64bit CPU?

Of course, yes. As I said above all 64-bit x86 CPU's are still fully compatible with 16-bit programs and by default still start in 16-bit real mode when boot in BIOS compatible way.

Are there any DOS versions (MS-DOS, FreeDOS, etc) that are entirely in 32bit (or even 64bit) so they can work fine on a 64bit CPU?

No, and even if such a 'DOS' would exist it would not be DOS compatible and could not run old DOS programs the same way as 16-bit DOS. Also such DOS is not even necessary since 16-bit MS-DOS/FreeDOS can still work fine with all current 64-bit CPUs.
The problem with booting/using MS-DOS/FreeDOS on modern systems will be that in the near future UEFI without CSM will be the norm:
https://www.techpowerup.com/238950/intel-to-r … rd-uefi-in-2020

Kerr Avon wrote:

Have we reached the point yet where DOSBox, running on the most powerful PCs available to the public, can emulate games faster than they can run in real DOS on any machines?

Not even close. Real DOS on a real P3 (maybe even P2) will outperform any machine running DOSBox.

But Dhrystone benchmark run in any virtual machine [QEmu (HAXM) or virtual pc or vmware player or virtualbox] with DOS outperforms Dhrystone benchmark run on the same PC booted to real DOS 😀

Guest outperforms host 😀

I would personally consider a true native DOS machine with decent sound hardware support for games ends with Intel 440BX platform and the best supported Intel CPU. Anything beyond that are simply half-hearted hacks and patches for extending the machine's DOS usability by check mark, while some worked some didn't do quite well. So given such a milestone, DOSBox may eventually outperform a true native DOS machine for another 15~20 years after year 2020, based on a 10X factor I use for pure emulation at best and CPU with sustained performance rate at over 10GHz. I believe this is something achievable by 2035~2040-ish without major breakthrough in quantum computing.

robertmo wrote:

But Dhrystone benchmark run in any virtual machine [QEmu (HAXM) or virtual pc or vmware player or virtualbox] with DOS outperforms Dhrystone benchmark run on the same PC booted to real DOS 😀

Guest outperforms host 😀

In theory, this is not possible. It is possible that virtual machines can play tricks with the reference tick count because virtual machines can indeed control the unit of time for each tick count. So it is not exactly fair to compare real DOS results with virtual machines if we are not sure how both of them derive the reference tick.

Another reason is for real DOS machine, interrupts can take place at absolute instruction boundary, while for virtual machine this is not always the case especially to achieve performance. For virtual machines employing hardware acceleration or dynamic recompilers, interrupts can only take place at boundary in block of instructions. So the same codes for benchmark can be interrupted at 1000 counts in real DOS machine, but on virtual machines only at 100 counts.