hmm a bit weird.
aep and ykhwong (and I think guilikoza as well)
all use mingw/GCC as well as their compiler.

My releases are gcc compiled, so don't throw gcc away so easily 😉. I'm also not doing any PGO, so I guess it beats VC too 🤣

There has also been some work done on the x86_64 core, when the platform is more widespread, dosbox should be ready...

Nice work frobme, I'd be very interested in VS2005 project files already set up for PGO.
edit: just figured out how to do it by myself 😊

gulikoza wrote:

My releases are gcc compiled, so don't throw gcc away so easily 😉. I'm also not doing any PGO, so I guess it beats VC too 🤣

There has also been some work done on the x86_64 core, when the platform is more widespread, dosbox should be ready...

I'd be interested in your compile set up then. I didn't do anything unusual; the gcc-3 builds are using the stock as-shipped MinGW version of gcc, on a stock tool chain. What are you CFLAGS for an average compile if you dont mind me asking? I tried several variations, changing -march and flipping between -O2 and -O3, etc (occasionally GCC will actually produce faster code with -O2).

I could run it through an exhaustive regression with acovea, but it's super rare for acovea to yield anything above a few percentage results. I'm not sure what could be accounting for the discrepancy. The EXEs are all stripped and are roughly in the size range of the VisStudio outputs.

Also, I did do runs with other SDL.DLLs, so that wouldn't seem to account for it. My configure is basically --enable-core-inline, nothing else seemed necessary.

-frob

Nothing fancy, MinGW latest gcc candidate (3.4.5), CFLAGS is a collection I gathered on the forum, nothing special I think:

1-mtune=i686 -march=i586 -O2 -pipe -fomit-frame-pointer -mno-push-args -ffast-math -funroll-loops --param max-unrolled-insns=60

Indeed O2 seems slightly faster 😀
I also have some graphic optimizations, my build will skip redrawing the screen if nothing has changed, but ykhwong has that too I think. You can also try to get my source tree, see if that is the difference compared to plain cvs.

[quote="gulikoza"]Nothing fancy, MinGW latest gcc candidate (3.4.5), CFLAGS is a collection I gathered on the forum, nothing special I think:

1-mtune=i686 -march=i586 -O2 -pipe -fomit-frame-pointer -mno-push-args -ffast-math -funroll-loops --param max-unrolled-insns=60

I'll try these flags, but that isn't my problem; I just rebuilt the entire set with gcc-3, gcc-4 again and I'm getting results more in line with yours. There appears to have been some fundamental issue with my initial pass on GCC; I'm not sure what, as I'm quite sure I used appropriate CFLAGS/CXXFLAGS, and the executables are the right size. In any case I'll edit the post in a moment, must be my error somewhere.

-Frob

Building with these CFLAGS/CXXFLAGS:

1-mtune=i686 -march=i586 -O2 -pipe -fomit-frame-pointer -mno-push-args -ffast-math -funroll-loops --param max-unrolled-insns=60

and using GCC-4.1.1 (what I had up in the environment when I went to test =) ) resulted in these numbers:

1gcc-4,gulikoza:    957,960,1019    avg 979  fps 76.6

If you have code that's not checked into the current CVS respository limiting screen draws, that could easily account for the discrepancy.

yeah - got the slowest one 😀

well, i'm not doing any optimizations at all 😉
just a
./configure host=i586-mingw32 && make

But my builds aren't for real daily use... more for daily testing (that's why they are updated daily too)

The following flag is what I use.

1CXXFLAGS="-s -O2 -pipe -fprofile-use -fomit-frame-pointer -mtune=i686 -march=i586" ./configure --enable-core-inline

I used to have gcc 4.1.x for mingw. It was slower than the gcc 3.4.5 for me.

ykhwong wrote:

The following flag is what I use. […]
Show full quote

The following flag is what I use.

Copy code to clipboard

1CXXFLAGS="-s -O2 -pipe -fprofile-use -fomit-frame-pointer -mtune=i686 -march=i586" ./configure --enable-core-inline

I used to have gcc 4.1.x for mingw. It was slower than the gcc 3.4.5 for me.

I'll check out a reference build with your flags as well, it will probably just turn in similar numbers to the downloaded version though.

It's quite possible gcc 4.1.X is slower than the 3-series, as they went through some really large changes in code base between those compilers. I'm interested in getting 4.3.X working it only to experiment, since it has a nocona (Core Duo) code emitter, just to see if it makes any difference. More often than not building to a specific proc has little effect though; so much so that Microsoft just threw the option out and always produces blended code now.

I was a little surprised at ICC's relatively middle showing here as it's historically been an excellent optimizer. Testing across three compilers like this with very similar results suggets that there isn't much in code generation that is going to make DosBox faster; rather if it gets further optimizations they will come from architectural changes or simple improvements in the approach of the code itself, not how it's compiled.

-Frob

Try benchmarking with Quake by starting it up with default everything (320x200, default viewsize with both status bars visible), in the start.bsp start position, with a timerefresh.

I usually test all of my computers this way over the years (P2 233 got 56fps, k6 500 gets 73fps, p100 gets 23fps, etc)

Note that -O2 is not terribly useful with PGO. If you use -fprofile-use (and I assume that you generated a profile with -fprofile-generate before), the really useful PGO-enabled optimizations are enabled by -O3, not -O2.

It's rather easy to explain why gcc-4 may seem slower than gcc-3, and O3 slower than O2 on some CPUs: Cache size. gcc-4's optimizer is way better, really. Unfortunately, many optimizations increase code size, and this can be a significant amount. So for normal builds, the gain of much better CPU optimization can easily be killed by more cache trashing, especially on low-cache CPUs like the Sempron, Celeron and some Intel Cores. The same reasoning applies to O2 vs. O3. gcc doesn't take cache size into account whle optimizing (although there are some options to influence code size).

The solution to this conflict is in fact PGO: with PGO, gcc is able to layout code so that often-used code parts are near each other, leading to less cache trashing (recent binutils are neede for that as well).

And another explanation, regarding the "bad performance with first build" mystery: When no profile information is present, gcc generates a random profile. This can in fact lead to identical builds that are not identical at all. The reason for this is empirical: The gcc folks simply tried it and found it generates noticeably better code most of the time.

`Moe` wrote:

The solution to this conflict is in fact PGO: with PGO, gcc is able to layout code so that often-used code parts are near each other, leading to less cache trashing (recent binutils are neede for that as well).

And another explanation, regarding the "bad performance with first build" mystery: When no profile information is present, gcc generates a random profile. This can in fact lead to identical builds that are not identical at all. The reason for this is empirical: The gcc folks simply tried it and found it generates noticeably better code most of the time.

Sensible but my tested GCC builds to date haven't been PGO'd =). Actually I went to run those through last night and ended up with a problem; even using the candidate 3.4.5 compiler, I can build the instrumentation pass fine, but the subsequent rebuild using the profile crashes in GCC. I didn't have a chance to test 4.1.1 yet. It's a shame the MinGW chain is so temperemental; I should have just immediately set up a cross compile environ on my Linux machine, but I get perverse about doing things the hard way sometimes...

-Frob

Yeah, that's what I mean: If you are doing a non-PGO build, it actually behaves a bit like a PGO build with random profile data. The reasoning is something like this: In some situation some decision must be taken, branches for example cannot be left out, so gcc has to guess which branch is more likely. Traditionally, branches a laid out just like the programmer did them. By using random statistical data and following data flow from that, it is actually possible to make better predictions in many cases. But since data is random, it is unlikely but perfectly possible that some builds behave noticeably worse.

By the way, gcc-4 is able to do full-program optimization, it would be an interesting experiment to check if that makes a significant difference. That's some work, however, since for that, gcc must compile the whole of dosbox in one go.

BTW, from what I have read, PGO on the 3.x series wasn't nearly as effective or stable as on the 4.x series.

`Moe` wrote:

Yeah, that's what I mean: If you are doing a non-PGO build, it actually behaves a bit like a PGO build with random profile data. The reasoning is something like this: In some situation some decision must be taken, branches for example cannot be left out, so gcc has to guess which branch is more likely. Traditionally, branches a laid out just like the programmer did them. By using random statistical data and following data flow from that, it is actually possible to make better predictions in many cases. But since data is random, it is unlikely but perfectly possible that some builds behave noticeably worse.

By the way, gcc-4 is able to do full-program optimization, it would be an interesting experiment to check if that makes a significant difference. That's some work, however, since for that, gcc must compile the whole of dosbox in one go.

BTW, from what I have read, PGO on the 3.x series wasn't nearly as effective or stable as on the 4.x series.

Ah, gotcha. I guess enough people don't follow the "stay on the path" recommendations for branch prediction logic flow for it to be useful to always guess one direction or another.

Sadly PGO doesn't seem to work for GCC-4.1.1 either; I can build and instrument fine, run the instrumented build, it creates a .gcda file etc. But when I rebuild the next pass with "-fprofile-use" I get an internal compiler error on both 3.4.5 and 4.1.1 (in different spots).

The whole program thing looks interesting, but it's very unfriendly to current makefile style. I suppose I could kludge some kind of huge cpp file together =)

-Frob

Traditionally, branches a laid out just like the programmer did them.

Actually this fact is used in several places to force faster code. ih8regs did
some testing on larger scope rearranging, which gained some speed.
The compiler works against this by using randomization in the prediction.
Of course pgo will still get it correct then, but it is not an option as games
vary largely in what code is actually used and which predictions are optimal.

wd, right, but I am with the gcc team here: code layout should follow logic and intentions of the programmer, not behaviour of one target machine (who knows, maybe in 5 years, branches are faster exactly opposite from today's branches). That's why we have the GCC_UNLIKELY macro (which I feel is misnamed, because I bet MSVC has something similar which might be used). That way, program logic and optimization are well visible and separated from each other.

On the other hand, and this is a very important point IMHO, a software that is released roughly once per year does not have any excuse not being profile optimized, making all these points moot. My personal builds always use profiling, I set up a simple shell script that runs dosbox on 5 quite different games with quite different hardware usage patterns, all that takes 1.5 times longer than a simple build and works perfectly well. 10 minutes longer for 10% more performance? Yes please.

frobme, I have no idea why it crashes for you. You are using mingw, right? Maybe that's something they didn't support correctly right now. With gcc-4, you should be able to use profile data from a linux compile on windows. gcc-3 is very picky about profile data, so if at all, gcc-4 can do that.

It's not really possible to find a low number of games which, when pgo'd,
would not have a lot other games behave quite bad. There are simply too
many factors, like graphics modes (if you have one game that requires
the custom memory access and which outweights all other memory access,
you'll get quite bad performance in most other games).
If really going that way you'd end up with several builds which are optimized
for different processor classes (and maybe even game classes). Think the
regular releases are ok speed-wise, and if you really need more speed you
can choose special architecture flags and pgo for one game. But this is
open for discussion, maybe you really have found a good set of games
that results in pgo builds which are faster for most games 😀

Well, I think even using just a text-mode program for PGO is better than none at all, since there's a lot in DOSBox that can be optimized and which is not graphics mode dependent. It should be easy to pick 5 "typical" programs for their age, programs that do not pull off weird tricks. Then you'd end up with a build for the average program which behaves as well for strange programs as the current builds, but much better for the bulk. Using a weird program doesn't mean anything else will be slow either, because much of the optimization will still be common for any program.