VOGONS


Reply 21 of 47, by Silanda

User metadata
Rank Member
Rank
Member

~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.

Reply 22 of 47, by Silanda

User metadata
Rank Member
Rank
Member

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.

Reply 24 of 47, by Silanda

User metadata
Rank Member
Rank
Member
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.

Reply 26 of 47, by Silanda

User metadata
Rank Member
Rank
Member

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.

Reply 27 of 47, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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

Water flows down the stream
How to ask questions the smart way!

Reply 29 of 47, by Silanda

User metadata
Rank Member
Rank
Member

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.

Reply 30 of 47, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie
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:

/* The internal types */
typedef unsigned char Bit8u;
typedef signed char Bit8s;
typedef unsigned short Bit16u;
typedef signed short Bit16s;
typedef unsigned long Bit32u;
typedef signed long Bit32s;
typedef unsigned __int64 Bit64u;
typedef signed __int64 Bit64s;
#ifdef _M_X64
#define C_TARGETCPU X86_64
typedef unsigned __int64 Bitu;
typedef signed __int64 Bits;
#else // _M_IX86
#define C_TARGETCPU X86
typedef unsigned int Bitu;
typedef signed int Bits;
#endif

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

Reply 32 of 47, by Kisai

User metadata
Rank Member
Rank
Member

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

syschk_0005.png
Filename
syschk_0005.png
File size
6.98 KiB
Views
672 views
File comment
64-bit MSVC2019 core=dynamic cycles=max
File license
Fair use/fair dealing exception

core=dynamic cycles=max

syschk_0004.png
Filename
syschk_0004.png
File size
6.8 KiB
Views
672 views
File comment
64-bit MSVC2019 core=dynamic cycles=3000
File license
Fair use/fair dealing exception

core=dynamic cycles=3000 (default)

syschk_0002.png
Filename
syschk_0002.png
File size
7.05 KiB
Views
672 views
File comment
64-bit MSVC2019 core=dynamic cycles=10000
File license
Fair use/fair dealing exception

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.

Reply 33 of 47, by Kerr Avon

User metadata
Rank Oldbie
Rank
Oldbie

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 😊

Reply 34 of 47, by superfury

User metadata
Rank l33t
Rank
l33t
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.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io

Reply 35 of 47, by Falcosoft

User metadata
Rank Oldbie
Rank
Oldbie
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

Website, Facebook, Youtube
Falcosoft Midi Player + Munt VSTi + BassMidi VSTi topic

Reply 36 of 47, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 37 of 47, by robertmo

User metadata
Rank l33t++
Rank
l33t++

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 😀

Reply 38 of 47, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 39 of 47, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
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.