Dominus wrote:

Thanks for your elaborate correction.
Let's say, in my experience during testing, I found the 32bit build still being faster than the 64bit build. This was on OS X.

Windows 10 1809 x64, Quake Shareware v1.06

1timedemo demo1
2
3My own build (MinGW64), DOSBox SVN r4267 (x64)  ~197 fps
4jmarsh's SVN DOSBox                      (x64)  ~195 fps
5
6Official DOSBox 0.74-3                   (x32)  ~153 fps
7EmuCR DOSBox SVN r4267                   (x32)  ~152 fps
8Yesterplay80's DOSBox SVN r4267          (x32)  ~147 fps

Again, Firtasik, thanks for the elaborate comment, doesn't change my direct experience that I'm drawing on.
but this is relevant:

jmarsh wrote:

You'd have to compare builds made from identical source+with (roughly) the same compiler... the build in the first post is made with VS9 (and missing quite a few optional features), I believe "official" builds are made with mingw.

Yeah, that 64-bit boost in my benchmark must be purely coincidental. The 32-bit counterparts would be "the fastest" of course. I hope you appreciate this elaborate comment as well.

Firtasik what if you try these:
Benchmarking emulators on latest machines

Considering the huge amount of DOS games you can't determine a speed difference without benchmarking more than one game.
Also you are probably better off benchmarking in situations that are actually useful like demanding games that don't run well in DOSBox or on host processors where a speed increase would be beneficial.
Optimization flags should be stated when DOSBox is compiled.

TLDR: By itself no one cares that Quake 1 can run at 200fps in DOSBox in fact it's probably for the worse that it does.

robertmo wrote:

i also had 32-bit faster on windows

I actually see 64-bit version faster on both Windows and Linux. It is way faster in Windows than in Linux compared to 32-bit counterpart. However, all my tests were focusing on pixels pushing instead of pure arithmetic, such as PCPBENCH, Quake2 3Dfx etc. I use latest GCC9 and compiled with:

1-march=native -mtune=native -O3 -fomit-frame-pointer

And, it is obvious that 64-bit code is always better at pushing pixel and pixel operations.

I don't know if jmarsh's implementation has an advantage on Windows since he is developing on Windows with the Windows ABI in the dynamic recompilation. I have seen similar performance difference between Windows and Linux on QEMU TCG that TCG is faster in Linux than in Windows as QEMU is 1st-class citizen on Linux.

64-bit Linux in general should be faster than windows due to a more sensible ABI.

jmarsh wrote:

64-bit Linux in general should be faster than windows due to a more sensible ABI.

I just built r4267 and the Windows version blow away the Linux version in:
- PCPBENCH at 800x600-16bpp LFB
- Quake1 3Dfx Voodoo chip emulation 800x600 (time demo1)
- Quake2 3Dfx OpenGlide pass-through 1024x768 (demo1.dm2)

This wasn't quite the case when I had both x32 versions on Windows and Linux. While Windows was still faster than Linux in x32, Linux was close, not more then 5%. Your 64-bit dynamic_x86 make it significantly faster at Windows on the same machine that dual-boot Windows 10 x64 and ArchLinux.

I had long abandoned Microsoft Visual Studio toolchain and not looked back ever, even though it is essentially freeware today. Back then when I still used VS, VS compiled DOSBox was way less optimized than MinGW.

You can look at the code for yourself; the only difference in risc_x64.h for windows vs. linux is that windows requires extra instructions to be emitted to save/restore RSI and RDI all the time. Executing more instructions by definition can't increase performance, the difference is likely due to things outside DOSBox being more optimized (e.g. graphics drivers).

kjliew wrote:

I just built r4267 and the Windows version blow away the Linux version in: - PCPBENCH at 800x600-16bpp LFB - Quake1 3Dfx Voodoo […]
Show full quote

I just built r4267 and the Windows version blow away the Linux version in:
- PCPBENCH at 800x600-16bpp LFB
- Quake1 3Dfx Voodoo chip emulation 800x600 (time demo1)
- Quake2 3Dfx OpenGlide pass-through 1024x768 (demo1.dm2)

1output=surface

Try not to compare different implementations of graphics drivers, d3d vs opengl / mesa. Another important difference is the SDL library and its differences in optimization under different systems.

linux x86_64 x86_32 core2 2GHz (dating from 2006)
pcbench 44.0 43.3
dhry1nd 57.18 53.88
quake1 demo1 61.5 57.4

ok, can we get back on topic. We have now established that for some 64bit is faster and for others it isn't. Regardless of that, Jmarsh' implementation and fixes catapulted DOSBox into the 64bit age with a huge, much needed boost and thankfully this is now in SVN!

digger wrote:

robertmo wrote:

time for core haxm 😀

I would love to see an optional hardware-assisted hypervisor core in DOSBox! 😀 Unfortunately, the DOSBox developers and maintainers have stated that they won't ever be going the virtualization route, for philosophical reasons. It's a shame, though. Having something like that, at least as an option, would be great for playing the later heavier 32-bit protected mode games from the twilight days of the DOS era on current modern-day hardware.

There are huge issues with virtualization and vga emulation. DOSbox may actually have an advantage here though with it's ability to change cpu emulations on the fly.

This patch is well timed for the coming wave of 32bit deprecations.
Fedora just announced they've dropped support for i686 32-bit builds starting with release 31, which is now in beta:

https://betanews.com/2019/09/17/fedora-linux-31-beta/

"If you want to download Fedora 31 Beta, you can grab it here. Thankfully, Fedora is now 64-bit only -- 32-bit x86 bootable ISOs are no longer being released. Before you install it, however, please remember this is a pre-release operating system. It is very likely to contain bugs, which could lead to potential data loss."

AFAIK they just dropped the kernel. Multilib is still supported on Fedora 31 unless something changed recently.

I've hit a regression with QEMM 97 locking up when it previously didnt, so I need to do a git bisect over the weekend and go back to before the 64bit patch dropped and see if thats the cause. 😒

Thanks for clarifyng DosFreak; their own blog neglected to mention that nuance.

So it's just hardware-side i686 support, while software-side will still support both x86_64 and i686 (running on exclusively 64bit hardware). Will be intersting to see if they continue building and supporting the full equivalent set of i686 RPMs or if they also drop most of them, and only provide build essentials and such.

The end of support for i686 in Archlinux came in November 2017. I use this distribution and I have no problems running and building applications under x86-32. In this and various versions of dosbox (32-bit), now with good support for x86-64 will be unnecessary for me and multilib will mainly be used only for wine.

I've never used a dosbox from the archlinux x86-64 repository, it was too slow.

Dominus wrote:

the 32bit one is still the fastest. So if you run DOSBox 0.74-3 you are good. But some operating systems are doing away with 32bit support and before this patch 64bit DOSBox was really way slower. This patch is awesome for those OS 😀
The patch is now in SVN so up to date SVN builds will have it and are way newer than the binary in the first post.
Hope this helps.

I understand now 😀 Thanks for the information!

BloodyCactus wrote:

I've hit a regression with QEMM 97 locking up when it previously didnt, so I need to do a git bisect over the weekend and go back to before the 64bit patch dropped and see if thats the cause. 😒

Why do you even need QEMM 97 in DOSBox? All DOS games will run just fine without it.

I have some disk images that I boot inside dosbox to do some testing with real ems drivers which dosbox does not provide (a real vcpi interface basically).