Interesting read. -fomit-frame-pointer in general helps a lot in performance it did for the GP2X.

core-inline doesn't help because you are running a game with the dynamic cpu core.
core-inline inlines the memory read and write functions in the normal cpu core only.
So to test the effect of that you have to set core=normal instead of core=auto.

Qbix wrote:

core-inline doesn't help because you are running a game with the dynamic cpu core.
core-inline inlines the memory read and write functions in the normal cpu core only.
So to test the effect of that you have to set core=normal instead of core=auto.

Ok. Thanks for the heads up.

I'm experimenting with GCC 4.3.1 now. Can't get DOSBOX 0.72 to compile with it (errors), but CVS is working.

I recall some includes missing for gcc 4.x
Should be fairly simple to port back from the cvs if needed

Yeah I did some file compares and rigged up a 0.72 with some fixed CPP files with the added includes. It worked. The compiler was warning about some sort of typedef mis-use too but it didn't seem to cause anything to fail.

GCC 4.3.1 won't make me a faster EXE though. I tried lots of stuff. Used the supposedly improved profiled compiling, tried the vectorizer, etc. It just can't quite beat the 0.72 compile I made above. It also made me a few non-functional compiles. Profiling + O3 doesn't seem to work right and DOSBOX immediately crashed, and a profiled vectorizer compile crashed too. And I was excited to try a profiled vectorized compile..... The render_scalers.cpp file gets vectorized in a ton of places. "Vectorized without profiling" is insignificantly faster than a non-vectorized compile. You'd think they could instrument the exe during profile generation to determine which vectorized loops really did perform and drop those that didn't.

Notably, CVS seems to compile fine and without any warnings. 😀

As Qbix already said you don't gain much from compiler optimizations as
(if you're using the dynamic core) the heavy parts are generated (recompiled)
where the compiler does not matter.
Only things like scalers or non-cpu hardware (adlib) benefit from better compiler
optimizations/profiling.

Yeah that's what I'm seeing. The only time compiler options that made a tangible improvement were O2 + profile guided optimization + omitted frame pointer with GCC 3.4.5 and DOSBOX 0.72. That gave me a small improvement of about 5% over the 0.72 compile on the DOSBOX site. Everything else, even vectorizing and mfpmath=sse, did basically nothing to improve or even worsen performance.

I haven't tested scalers much at all because a) I don't like them most of the time b) they are slower than just using ddraw to scale.

I'm trying to understand the code better but obviously it's a major endeavor to get a grasp on the stuff you guys have put together. C++ is easy to read of course, but understanding the hardware emulation is another story.

For your information purposes:
DOSBox 0.72 was compiled with GCC 3.4.4

1CXXFLAGS=" -s -O3 -fomit-frame-pointer -ffast-math -march=i586 -mtune=i686 -fexpensive-optimizations"
2and 
3 --enable-core-inline

-O2 instead of -O3 might be faster. At least I had that feeling a few times. but it is hard to benchmark.

even vectorizing and mfpmath=sse, did basically nothing to improve or even worsen performance.

The dynamic core uses some non-trivial loading/saving of the fpu state which
might not work well together with mmx/sse/whatever code in other parts of
the emulation (it's funny that it works at all *g* ).

swaaye wrote:

out of the little 900MHz Celeron M inside it

Unless you have 'over'clocked it, it actually runs on 630MHz, since it is underclocked by default.

JAL

Actually, on the Eee900 it starts at 900 MHz. There is an option in the BIOS for "power save mode" which puts it at 630 MHz and undervolts everything. On "performance" mode, it starts at 900 Mhz and I've found that it'll do 1000 MHz fine. On power save, it can only handle 750 MHz oc.

swaaye wrote:

Actually, on the Eee900 it starts at 900 MHz. There is an option in the BIOS for "power save mode" which puts it at 630 MHz and undervolts everything. On "performance" mode, it starts at 900 Mhz and I've found that it'll do 1000 MHz fine. On power save, it can only handle 750 MHz oc.

Ok, that's good to know, as I've got a 900. The wiki on eeeuser.com is quite out of date.

JAL

I've found that my Athlon 64 3000+ in my big notebook is a little over 2x faster than this EeePC at 1000 MHz. Going by a Quake timedemo. With the same compile optimized for a Pentium M 🤣. Poor little Dothan CPU misses its 2MB cache I think. The A64 is an old Clawhammer with 1MB L2 @ 1800MHz.

Sigh... I was being lazy and downloaded the precompiled executable, only to find out it was a Windows EXE (I'm running Linux 😀)

JAL

well you'll just have to try to figure out how to build it on there. 😀

yeah, no doubt I can, but then I have to find out how to install gcc, sdl, and the whole muck, and I was happy to avoid that 😀.

JAL