try speeding up both dosboxes as it is said in Dosbox Guides and compare them again.

Probably the binaries aren't compiled with all inlining options and best optimisations

I enable the inline options during configure... --enable-core-inline... like usual. What other optimizations are there?

just in case:
ieremiou: your build is from 25th june
21th june build is on that page you gave link to a few days ago

yeah, i know. Just saying that I know what I'm doing I hope. :p...

Btw... Compiling new build for all you people who follow the DOSBox CVS Builds.. July 4th Edition :p...
Now if only I could CTRL+F12 my computer to speed up its cycles during compiling 🤣.

I think I use some different flags, not sure though.
you could compare your and my debug builds someday.

Hi.
Ok, I've done some more testing.

Original v0.61: 17000 cycles
Snapshot from cvscompile (21th June): 11300 cycles

Next I got sources from 3rd July, compiled with MinGW on WinXP.

./configure --disable-debug --enable-dynamic-x86 --enable-fpu --enable-opengl gave me more or less the same result as exe from cvscompile.

Adding --enable-core-inline: 15100 cycles (almost 4k more)

CXXFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer": another 500 cycles more (15600)

The best result I got was 15600, which is still less than 17000 0.61 gave me.

I've read somewhere on this forum, that CVS is generally faster than 0.61. Can you guys give me any hints, why this isn't true on my case?

t.

ps. I made those tests using the same dosbox.conf and running the same program (which was demo "Juice" by Psychic Link. Good for testing I think, as it requires lots of CPU power. Runs smooth on dynamic core and around 28000 cycles, but hangs badly after a minute or so)

the cvs is different not necisairy faster.
Some games are faster in it because certain bugs got fixed or some specific algortithm got faster.

In general this doesn't have to be the case.

(to support more complex games the cpu emulation has to support more complex states which might cause a little slow down in emulation)

Try experimenting with frameskip as well as the rendering functions changed a lot.

Your compiler version of course important as well.

I assume you compiled 0.61 yourself as well ? else it's not a fair comparison

Try experimenting with frameskip as well as the rendering functions changed a lot.

I use output=openglnb, as it's much faster for me than surface or overlay (I have NV GF3). Normally I set frameskip to 1, 2 doesn't make a big difference, and higher values make it loose smoothness.

Your compiler version of course important as well.

Thread model: win32
gcc version 3.2.3 (mingw special 20030504-1)

I assume you compiled 0.61 yourself as well ? else it's not a fair

I tried, but I got following error:

Making all in gui make[3]: Entering directory `/home/tomba_/dosbox-0.61/src/gui' g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../in […]
Show full quote

Making all in gui
make[3]: Entering directory `/home/tomba_/dosbox-0.61/src/gui'
g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../include -march=athlon-xp -O3 -pip e -fomit-frame-pointer -I/usr/local/include/SDL -Dmain=SDL_main -c -o sdlmain.o `test -f 'sdlmain.cpp' || echo './'`sdlmain.cpp
sdlmain.cpp: In function `void GFX_SetSize(unsigned int, unsigned int, unsigned
int, double, double, void (*)())':
sdlmain.cpp:335: `glPixelDataRangeNV' undeclared (first use this function)
sdlmain.cpp:335: (Each undeclared identifier is reported only once for each
function it appears in.)

t.

oh yeah. new sdl and 0.61 dosbox not good.
http://cvs.sourceforge.net/viewcvs.py/dosbox/ … r1=1.63&r2=1.64

Ok, 0.61 speed compiled by me is more or less the same as original. Well, guess it has to be that way 😀.

One more question: is there a way to get an up to date (including new options) dosbox.conf?

t.

um read the documentation ?

inside dosbox
config -writeconf dosbox.conf

For those using gcc/mingw/djgpp, be sure to use: "-funroll-all-loops" in your CXXFLAGS, and possibly "--param max-unrolled-insns=60" (although the latter effect should be small).

Make sure you use a recent GCC, that's very important: The loop unroller used to be very buggy until gcc-3.1, and generally the optimizer gets better and better at each release.

Profile guided optimization may also pay off: compile with "-fprofile-arcs"(+ your regular CXXFLAGS), keep the sources(!), run a few games (preferrably a wide range of different games), then recompile the same sources with "-fbranch-probabilities"(+ your regular CXXFLAGS). I haven't tested this myself yet, but that should yield another 5% speed.

(gcc will insert some code to write out statistics about program execution, which the second run can use to optimize better.)

Qbix: 😊

Moe: thanks, I'll try it too.

t.