search

joncampbell123 / dosbox-x

DOSBox-X fork of the DOSBox project
GNU General Public License v2.0
2.78k stars 381 forks source link

Documentation: compiler optimizations #242

Open ghost opened 7 years ago

ghost commented 7 years ago

Interesting discussion here: http://stackoverflow.com/questions/19470873/why-does-gcc-generate-15-20-faster-code-if-i-optimize-for-size-instead-of-speed

Noted this recommended optimization in place of -O2: -O2 -falign-functions=1 -falign-jumps=1 -falign-loops=1 -falign-labels=1

Is offering from 1% to 3% better performance in a GLQuake timedemo where core=normal and the 3dfx software rasterizer path. Also, UT seems more responsive in-game. It's possible that the timedemo does not capture the full advantage of this optimization scheme since these games may bottleneck in the rasterizer code. Further testing needed.

ghost commented 7 years ago

A general comment not necessarily related to dosbox-x:

I haven't test the following yet, but there are gcc linker options to increase the stack and heap size (at least in win32 which typically defaults to 1 megabyte; options for gcc 3.0 and later). I wonder whether this also applies to gcc for DOS and/or Linux (ulimit command may be an alternative). These are for larger sizes: -Wl,--stack=0x1000000 -Wl,--heap=0x1000000

Quake 3 seems to compile in DOS by hard linking its libraries, but the renderer does not display an image. It is possible that the issue is related to the stack size offered by the dpmi provider since this occurs in other Id engines. If gcc for DOS is capable of increasing its stack size beyond 1 megabyte, then perhaps the dpmi provider could access the larger size, too.

joncampbell123 commented 7 years ago

Didn't pan out? Or did you close for other reasons?

ghost commented 7 years ago

Sorry that I missed your reply - I should figure out how to enable notification for thread changes.

I did try various changes to stack and heap sizes with mingw32/gcc46, but I recall that these linker options were not available in djgpp. I can verify again. However, changing the sizes in mingw didn't seem to cause any issues.

I had noticed errors in dos builds by djgpp where changing stack size beyond 1mb. I hoped that this probable limit is specified by gcc/djgpp, but I now think it may be elsewhere since I tried different gcc versions. I don't think the limit could be in its dpmi provider; I recall verifying it the source code, but I'd have to find a better way to test.

As an interesting aside, it seems that gcc versions change their optimizations in a way that causes math calculation problems. Somewhere in the gcc4 branch there was an optimization that may rearrange lines in a code block for performance, but that can cause inconsistency among compiler versions.

I also confirmed that -O0 is not the same as -O2 with all documented O1/O2 optimizations removed. I tried that too, and verified that there are optimizations beyond what is documented as O1 and O2. I looked through the gcc source code and left it as an open problem.

ghost commented 7 years ago

Perhaps the one issue is related to mesa: http://www.3dfxzone.it/enboard/topic.asp?TOPIC_ID=730

Probably a better test is to use an older version of mesa and see if it works with Quake3 in Windows. However, I haven't yet checked why djgpp doesn't have the stack/heap linker options.