VOGONS


FastDosbox 1.6

Topic actions

First post, by slacka

User metadata
Rank Newbie
Rank
Newbie

I just built the latest FastDosbox 1.6 for my Ubuntu box. The speed is nothing short of phenomenal.
MIPS 1.1 is literately off the charts, a 3-100x increase over vanilla DOSBox depending on the benchmark. Second reality ran without any jank. Amazing!

If you want to try it out, you can download the source from:
http://gaming.capsule-sa.co.za/?gamepress_rev … ian-and-risc-os

# tar -xvf ../fastdosbox-1.6_src.tar.gz
# make

the binary will be in fastdosbox-1.6/src

I'd love to see some of these patches make their way into DOSBox SVN Daum

Last edited by slacka on 2014-02-18, 15:11. Edited 1 time in total.

Reply 2 of 19, by slacka

User metadata
Rank Newbie
Rank
Newbie

I never said "Pi" anywhere in my post. So what are you talking about? I said my "Ubuntu box" and by vanilla, I meant the version you get with
# sudo apt-get install dosbox

Even when I copied fastdosbox-CVS.conf over to my dosbox.conf, FastDosbox was still 2-5x faster. I'm surprised there's not more talk about it around here.

Reply 3 of 19, by Pickle

User metadata
Rank Member
Rank
Member

I wonder if people are paying $1 to have the dynamic core turned on for them...

Reply 4 of 19, by Jorpho

User metadata
Rank l33t++
Rank
l33t++
slacka wrote:

I never said "Pi" anywhere in my post. So what are you talking about?

It's there in the URL:
fastdosbox-for-raspberry-pi-raspbian-and-risc-os

Reply 5 of 19, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie
Pickle wrote:

I wonder if people are paying $1 to have the dynamic core turned on for them...

I think you're right... there's barely any noteworthy changes in the source code, besides making the default core "dynamic" instead of "auto".

Reply 6 of 19, by slacka

User metadata
Rank Newbie
Rank
Newbie
jmarsh wrote:
Pickle wrote:

I wonder if people are paying $1 to have the dynamic core turned on for them...

I think you're right... there's barely any noteworthy changes in the source code, besides making the default core "dynamic" instead of "auto".

But if that's true, why then is it so much faster on benchmarks like topbench even when I use the fastdosbox-CVS.conf setting in my dosbox.conf? If fastdosbox only changed configuration options, they would run at the same speed. I benched it against both DosBOX .74 and DOSBox SVN Daum.

Reply 7 of 19, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Try your benchmarks again when 0.74 has settings of core=dynamic cycles=max. This so-called fast build could simply be using dynamic core and max cycles with the default core=auto cycles=auto settings regardless of the CPU being in real or protected mode.

Reply 8 of 19, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie
slacka wrote:

But if that's true, why then is it so much faster on benchmarks like topbench even when I use the fastdosbox-CVS.conf setting in my dosbox.conf? If fastdosbox only changed configuration options, they would run at the same speed.

Those two statements are contrary to each other. If you can take the default .conf file generated by fastdosbox and get a speed up when using it with regular dosbox, obviously the speed up is simply because of different settings and not code changes.

Reply 9 of 19, by slacka

User metadata
Rank Newbie
Rank
Newbie
jmarsh wrote:
slacka wrote:

But if that's true, why then is it so much faster on benchmarks like topbench even when I use the fastdosbox-CVS.conf setting in my dosbox.conf? If fastdosbox only changed configuration options, they would run at the same speed.

Those two statements are contrary to each other. If you can take the default .conf file generated by fastdosbox and get a speed up when using it with regular dosbox, obviously the speed up is simply because of different settings and not code changes.

I copied the setting from fastdosbox-CVS.conf and pasted them into my Dosbox's dosbox.conf. I then benchmarked DosBOX vs fastdosbox. fastdosbox was still faster on some benchmarks. Why is this so difficult for people here to comprehend? And yes ripsaw,I was using core=dynamic cycles=max, because those are the setting that were copied out of fastdosbox-CVS.conf. Same settings, so it should be a fair benchmark comparison, right?

In addition, I ran
# apt-get source dosbox

Then performed a diff with fastdosbox's source. There are countless changes, especially in the CPU core. With all the negative comments without facts behind them, It's clear no one else here has either 1) benchmarked it or 2) looked at the source. Otherwise we be having a much more interesting discussion around all the many changes in paging.cpp and callback.cpp along with a few in core_dynrec.cpp.

Last edited by slacka on 2014-02-26, 14:09. Edited 3 times in total.

Reply 10 of 19, by truth_deleted

User metadata
jmarsh wrote:

I think you're right... there's barely any noteworthy changes in the source code, besides making the default core "dynamic" instead of "auto".

Moreover, that web site from OP states that the emulation is at 386/DX speed, which is not consistent with the speed-up claim. I believe there is also a patch in the patches subforum for ARM dynrec code.

Reply 11 of 19, by slacka

User metadata
Rank Newbie
Rank
Newbie
truth5678 wrote:
jmarsh wrote:

I think you're right... there's barely any noteworthy changes in the source code, besides making the default core "dynamic" instead of "auto".

Moreover, that web site from OP states that the emulation is at 386/DX speed, which is not consistent with the speed-up claim. I believe there is also a patch in the patches subforum for ARM dynrec code.

My original post was referring to the 1.6 Ubuntu build. Not the old 1.5 Pi build that people keep bringing up. The 386/DX speed is when it's running on a lowly $25 ARMv6 board. I don't know DosBOX compares on this hardware, although this site says FastDosBox runs much better than normal DosBOX on a Pi.
http://www.codingepiphany.com/2013/06/29/fast … ith-fastdosbox/

Besides, my benchmarks were done on an x86 Ubuntu box. I don't see how an older Pi version's performance is relavent.

How do all these "believers" and "thinkers" that fastdosbox is just a config tweak, explain this:
http://pastebin.com/GWeu985r

Reply 12 of 19, by truth_deleted

User metadata

That link shows very few changes to the source code and many of the lines are identical in source. When creating a diff file, it is important to identify changes resulting from empty spaces and lines in the code. The diff command will show a difference from empty spaces and lines. The several changes are slight modifications (and M-HT has already written ARM dynrec code as shown here: Dynrec - ARM backend update).

The ARMv7 dynrec code has already been submitted by M-HT about a year ago.

Reply 13 of 19, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

The reason why no one believes you is because it's very hard to quench more speed out of dosbox. I'll try myself with that source but I'm not hopeful...
Likely explanations that haven't come up yet:
- Try with DOSBox SVN
- make sure both builds are on the same arch (32bit vs 64bit)
- if fastdosbox was built as 64bit then maybe THERE are optimizations for the 64bit dynrec core

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 14 of 19, by slacka

User metadata
Rank Newbie
Rank
Newbie

@Dominus
I already tested with SVN Daum. Did you have a particular one i mind?

When using the same configs, many benchmarks were similar, but fastdosbox still managed to consistently win on MIPS.COM and topbench. The results were as follows:
FastDosbox > DOSBox SVN Daum w/ FastDosbox config > vanilla DOSBox 0.74

I did all my testing and compiling on a 32-bit Ubuntu box. I don't have Linux installed on a 64-bit PC.

Last edited by slacka on 2014-02-20, 02:36. Edited 1 time in total.

Reply 15 of 19, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Best would be if you could just grab Dosbox svn and test with that. Because SVN has lots of fixes but isn't overburdened as Daum's "fork"

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 16 of 19, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie
slacka wrote:

In addition, I ran
# apt-get source dosbox

Then performed a diff with fastdosbox's source. There are countless changes, especially in the CPU core.

There really aren't, if you ignore whitespace changes (and compare against say, dosbox SVN r3783 since fastdosbox is missing a lot of more recent bugfixes).

With all the negative comments without facts behind them, It's clear no one else here has either 1) benchmarked it or 2) looked at the source. Otherwise we be having a much more interesting discussion around all the many changes in paging.cpp and callback.cpp along with a few in core_dynrec.cpp.

The only person making up facts is you; those three files are functionally identical to older dosbox code. You can tell just by looking at the file modification dates: callback.cpp is dated 2012 and paging.cpp is dated 2011.
fastdosbox doesn't even have the MEM_BlockWrite/MEM_BlockRead patch that greatly improves disk I/O speed and stands out as obvious low-hanging fruit if you run dosbox while profiling.

How do all these "believers" and "thinkers" that fastdosbox is just a config tweak, explain this:
http://pastebin.com/GWeu985r

There is nothing in there that could be considered as a new optimization.

Reply 17 of 19, by Pickle

User metadata
Rank Member
Rank
Member

one possibility for some optimization is using the gpu to do the scaling, for instance in my pandora build I render with no scaling and use the 2d hw scaler to fill the screen. This helps get a bit more speed, but doesnt seem to be the complete answer to the speed up claims.

Reply 18 of 19, by slacka

User metadata
Rank Newbie
Rank
Newbie

Per Dominus's suggestion, I finally got around to building the latest SVN and it looks like that's where the speed up in certain tests was coming from. Sorry if I got anyone's hopes up.