VOGONS


64-bit dynamic_x86 (patch)

Topic actions

Reply 60 of 123, by Firtasik

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

timedemo demo1

My own build (MinGW64), DOSBox SVN r4267 (x64) ~197 fps
jmarsh's SVN DOSBox (x64) ~195 fps

Official DOSBox 0.74-3 (x32) ~153 fps
EmuCR DOSBox SVN r4267 (x32) ~152 fps
Yesterplay80's DOSBox SVN r4267 (x32) ~147 fps

11 1 111 11 1 1 1 1 1 11 1 1 111 1 111 1 1 1 1 111

Reply 61 of 123, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

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.

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 62 of 123, by Firtasik

User metadata
Rank Oldbie
Rank
Oldbie

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.

11 1 111 11 1 1 1 1 1 11 1 1 111 1 111 1 1 1 1 111

Reply 64 of 123, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

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.

How To Ask Questions The Smart Way
Make your games work offline

Reply 65 of 123, by kjliew

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

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

Reply 67 of 123, by kjliew

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

Reply 68 of 123, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie

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

Reply 69 of 123, by latalante

User metadata
Rank Newbie
Rank
Newbie
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)

output=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

Last edited by latalante on 2019-10-06, 10:27. Edited 1 time in total.

Reply 70 of 123, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

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!

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 71 of 123, by crazyc

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

Reply 72 of 123, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

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

Reply 73 of 123, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

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

How To Ask Questions The Smart Way
Make your games work offline

Reply 74 of 123, by BloodyCactus

User metadata
Rank Oldbie
Rank
Oldbie

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

--/\-[ Stu : Bloody Cactus :: [ https://bloodycactus.com :: http://kråketær.com ]-/\--

Reply 75 of 123, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 76 of 123, by latalante

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 77 of 123, by Kerr Avon

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

Reply 78 of 123, by kjliew

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

Reply 79 of 123, by BloodyCactus

User metadata
Rank Oldbie
Rank
Oldbie

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

--/\-[ Stu : Bloody Cactus :: [ https://bloodycactus.com :: http://kråketær.com ]-/\--