VOGONS


First post, by *orz*

User metadata
Rank Newbie
Rank
Newbie

Hello:

I downloaded the dosbox source a few days and have been fiddling around with it. It's a swell project!

Performance is WAY better than it was in the 0.61 release. Games like privateer and doom that were completely unplayable for me in 0.61 are now mostly playable with the CVS version.

I thought I'd do some benchmarking to figure out what needs improvement. Benchmarking was complicated however by the fact that programs inside of DOSBox use a "virtual" (non-real) time, which slows down if DOSBox can't simulate as fast as it wants to. To make benchmarking easier, I modified DOSBox to use real time instead (i.e. in-game time is synchronized to actual time). For benchmarks, I wrote a few simple C programs, and compiled them with VC 7.1 and gcc 3.3.3/DJGPP. I tested the DJGPP version in both a windows dosbox and in DOSBox. All tests were done on my Athlon Thunderbird 1Ghrz.

Test1 - (some simple math):
win32:
raw result - 155 krand / second
percentage of optimum - 98%
estimated cycles - about 800k

windows dosbox:
raw result - 158 krand / ms
percentage of optimium - 100%
estimated cycles - about 800k

DOSBox (normal):
raw result - 1.58 krand / ms
percentage of optimum - 1.0%
estimated cycles - about 8 k

DOSBox (full):
raw result - 1.32 krand / ms
percentage of optimum - 0.84%
estimated cycles - about 7 k

DOSBox (dynamic):
raw result - 14.4 krand / ms
percentage of optimum - 9.1% - WOW!!!
estimated cycles - about 73 k

Test2 - (some memory access, a little math):
win32:
raw result - 95 scrambles / ms
percentage of optimum - 99%
estimated cycles - about 1300k

windows dosbox:
raw result - 96 scrambles / ms
percentage of optimium - 100%
estimated cycles - about 1300k

DOSBox (normal):
raw result - 0.61 scrambles / ms
percentage of optimum - 0.64%
estimated cycles - about 8.5 k

DOSBox (full):
raw result - 0.48 scrambles / ms
percentage of optimum - 0.50%
estimated cycles - about 6.5 k

DOSBox (dynamic):
raw result - 4.54 scrambles / ms
percentage of optimum - 4.7% - pretty damn good!
estimated cycles - about 62 k

There WAS a third test, which tested writting to video memory in mode13h, but both full and dynamic refused to run it, and normal, windows-dos-box and windows gave it results similar to what they gave test2. It used the Allegro library to do the graphics portably.

The dynamic core gives some very impressive results. I can't get privateer to work with it, but doom seems happily playable with it. I can't remember how to get doom to give performance data, so no quantification on that. I seem to remember some command line parameter yielding a set of dots at the bottom of the screen corresponding to the vtraces between frames...

If anyone knows of good benchmarks for measuring performance, let me know. The ideal candidate would give quantifiable performance data, run on modern computers, run in dosbox in all modes, be extremely limber, nubile, and er...

More:

I think the time concept tweak that I did for benchmarking would be a nice addition to the normal DOSBox. It makes tuning for 486 games more convenient - I just set cycles to 199000, and don't worry about it until I want to play a really old game that isn't timed to the clock. This is how I currently have it set up:

1. The cycles is treated as a maximum per ms instead of the hard amount per ms. If it detects that real time has elapsed, it will skip cycles until its caught up.
2. A setting was added to the CPU section of the .conf file, synchedtime=true. This then effects a variable bool CPU_SynchedTime. If that variable is false, time works like it did without this code.
3. Pressing control-equals toggles synched time mode. You can tell which mode you're in by looking at the title bar. In unsynched mode it will say "Cycles = %d". In synched mode it says "Cycles < %d". (it used to say "Cycles: %d")

More More More!

1. in CPUID, "Intel" is mispelled : o)
2. there was some initialization stuff that was intentionally dereferencing NULL pointers for silly reasons. I fixed it in mine and emailed a patch with the fix to Qbix.
3. the DOS_Drive_Cache is crashing for me, reproducably. I can describe in how it crashes (I've watched it in the debugger), but I dunno how to fix it. The code is on crack!

So am I.

Reply 1 of 15, by tonyi

User metadata
Rank Newbie
Rank
Newbie

I don't know of anything that timed specific instructions, I always use the timings from the Intel manuals when I do optimization work.

Perhaps a more important effort would be to create some sort of single-step profiler that would tally up occurances of particular instructions in various apps. That would locate what areas need the most attention and give best bang for the buck when optimizing.

Can't fix the thing if you don't have the shit. If you don't have the shit, you can't fix the thing.

Reply 3 of 15, by priestlyboy

User metadata
Rank Oldbie
Rank
Oldbie

Yeah, I remember bring up the Dynamic Core thing with the DOSBox Devs. They say it'd get really messy so they aren't sure if they would work in the Dynamic core for Privateer.

Ieremiou
----------
Helping Debug DOSBox.

Reply 4 of 15, by *orz*

User metadata
Rank Newbie
Rank
Newbie

Wow, no response for a month then 3 responses in a single day.

Anyway, here is a patch (against CVS as of yesterday) for the functionality I described in that post. The patch also includes a bugfix for the DriveCache issue I mentioned.
http://orz.dnip.net:742/dosbox_timesynch.patch

Here is the binary for the version that I'm currently using... it's based off of an older copy of CVS, and has a bunch of random changes stuck into it without discipline. When time is synched in this version, it completely ignores the set Cycle rate and just runs as fast as it can. Also, it measures the performance and displays it, both in synched mode and normal mode. Also, pressing Control-1 switches to normal core, Control-2 switches to Full core, and Control-3 switches to Dynamic core, and it displays which core is currently in use.
http://orz.dnip.net:742/dosbox.exe
http://orz.dnip.net:742/dosbox_upxed.exe

By switching cores for the startup of Privateer, I can get it (and almost anything else) to work with the Dynamic core. Unfortunately, Privateer doesn't work very well with the Dynamic core... mouse input gets horribly lagged.

I'm currently using ByteMark / NBench for dosbox benchmarking purposes.

p.s. the latest CVS consistently crashes for me if I set the cycles to a low value

UPDATE: all of these links are down now... I'm in the process of moving and won't be serving anything for a few weeks.

Last edited by *orz* on 2004-07-04, 21:13. Edited 1 time in total.

Reply 5 of 15, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

Thanks for the patch. I've compiled todays cvs version with it but I cannot get time to sync. I've set timesynched=true in the config file but cycles always stay at =. Btw: what key is MK_equals?
But your build works great! I'd really like to see some of this patches in the cvs, I think there's a lot to be gained 😁
I did however experience some problems with Norton Utilities sysinfo. Dosbox crashes shortly after displaying CPU Benchmark. I haven't tested a lot so it might be a problem with vanilla cvs version as well...

Reply 6 of 15, by *orz*

User metadata
Rank Newbie
Rank
Newbie

Control-Eqauals will toggle it into that mode. The MK_equals key in question is the equals key next to backspace on my keyboard which doubles as a plus key when shift it pressed (i.e. SDLK_EQUALS). Sorry about the .conf setting not working... I was filtering out all the unrelated changes I'd made to my version and accidentally removed a piece necessary for that:
secprop->Add_bool("timesynched",false);
needs to be added to dosbox.cpp, right after
secprop->Add_int("cycledown",20);
(which is line 234 in my copy).
I've updated the patch to include that.

Reply 7 of 15, by *orz*

User metadata
Rank Newbie
Rank
Newbie
tonyi wrote:

Perhaps a more important effort would be to create some sort of single-step profiler that would tally up occurances of particular instructions in various apps. That would locate what areas need the most attention and give best bang for the buck when optimizing.

I've attempted to implement this idea, but it's not working too well so far. I'm getting the instruction name from the disassembly string which means that "mov eax, ebx" qualifies as a different instruction than "mov ebx, eax". I'm also measuring the average time to execute each instruction, and the standard deviation of that. Maybe with a bit more work it might have some use...

edit: maybe the first byte of the opcode after the prefix bytes would be a more appropriate key for the profile data...

Reply 8 of 15, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

Amazing...Tie Fighter Collector's CD is actually playable with your version in SVGA 😁 What I've found interesting is that with the dynamic core in timesynced mode (non-synced is ok) all the non-flying scenes are extremely slow - but since it's possible to change cores and timesync flag on-the-fly I don't see it as a problem at all. btw: is there something special that needs to be done for joystick to function? I have joystick support in your compiled version, but not if I compile myself (all the binaries are ofcourse in the sam directory, using the same config)?

Reply 9 of 15, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

hmm...nevermind. It seems it's broken in the latest cvs 🙁. There seems to be a bunch of joystick initialization calls missing. After copy-paste from 0.61 sources it did compile & detect my joystick, but it's still not working...

Reply 12 of 15, by tomba

User metadata
Rank Newbie
Rank
Newbie

Thanks. This patch generally works really, really well. I have some problems with dynamic core though 😒. Sometimes the sound is garbled, and sometimes gfx looks like this:

http://bartek.tu.kielce.pl/~tomba/dosbox/caero_001.png
http://bartek.tu.kielce.pl/~tomba/dosbox/caero_004.png
http://bartek.tu.kielce.pl/~tomba/dosbox/state_000.png
http://bartek.tu.kielce.pl/~tomba/dosbox/state_001.png

Switching it back to normal core make those problems go away, but then - it's slower 😀

t.

Reply 13 of 15, by priestlyboy

User metadata
Rank Oldbie
Rank
Oldbie

Patching these into the latest CVS *had to modify them a little due to some changes in the core CVS again* for the Unoffcial DOSBox CVS build. Should be released July 13th. :p.

Ieremiou
----------
Helping Debug DOSBox.

Reply 14 of 15, by tomba

User metadata
Rank Newbie
Rank
Newbie

Hi.
I've played a bit more with this patch and I noticed, that my problems with sound and gfx are caused by the following fragment:

if((CPU_TimeSynched) && (current_tick != LastTicks))
CPU_Cycles = 0;

Setting CPU_Cycles >0 seem to help (in my case even 1 is enough for sfx, around 10 for gfx)

t.

Reply 15 of 15, by joe_pool_is

User metadata
Rank Newbie
Rank
Newbie

priestlyboy wrote:

Patching these into the latest CVS *had to modify them a little due to some changes in the core CVS again* for the Unoffcial DOSBox CVS build. Should be released July 13th. :p.

That post was in July 2004. Is this implimented in the 0.63 release of DOSBox already, or is it still just an add-on patch?

Wanted: Gasoline and matches.