Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

Compilation speed with GCC (Developers)

posted by Rugxulo Homepage, Usono, 09.09.2008, 22:16
(edited by Rugxulo on 10.09.2008, 16:07)

> 1). "-O0" (or -O2 instead of -O3) [older -O2 is as fast as newer's -O0)
-Os seems to in some cases be faster to compile than -O2. However, it seems 3.4.4 and 4.3.0 are faster output with -Os than any version in between (e.g. 4.1.2 or 4.2.3), at least in my tests. (Your results may vary, obviously.)

> 3). distcc (e.g. under Cygwin via cross-compiler: e.g. 3.4.x w/ 3.4.x on 2
> PCs)
Cygwin seems to by default still use GCC 3.4.4 due to various issues (exceptions, .DLLs, etc). MinGW is at 3.4.5 "stable".

> 6). fully-defragged HD (full optimization w/ name sort)
"[on FAT] Even if CHKDSK.EXE is the first .EXE found in your directory, it still has to keep looking for a possible CHKDSK.COM, which would take precedence." (i.e. HPFS is supposedly better than FAT)

> 9). "-mtune=i686" (faster than DJ's default "-mtune=pentium", on a P4 at
> least)
Not sure about this. For 3.4.4, compiling TDE 5.1v (C) targeting 486 is a lot faster, but -mtune=i486 for paq8o8z (C++) is a lot slower (according to -fstats, wasting more time internally in GCC's "expand", whatever that is). Since the 486 is in-order execution and has static instruction timings, shouldn't it always be simpler/faster to compile for that??

> 10). recompile GCC + BinUtils w/ newer GCC (and/or using something like
> "-march=pentiumpro -mtune=i686"
For some reason, GCC's -march=pentiumpro always assume CMOVs, which (supposedly? says Alan Cox in 2002) isn't always the case. And even 4.3.0 does the same. Weird.

> 11). set TMPDIR= to moderate-sized RAM disk
Using 4.x's -combine (C only) will supposedly only write one .o file for multiple sources (untested by me).

> 12). (this didn't seem to help but I'm mentioning it anyways):
> tweak "--param ggc-min-expand=30 --param ggc-min-heapsize=4096"
> (DJGPP's default)
Apparently, if you have lots of RAM (e.g. >= 1 GB), which I did notice on Ubuntu using by default, GCC seems to use --param gcc-min-expand=100 --param ggc-min-heapsize=131072. However, DJGPP doesn't automatically detect this for me on Vista (maybe because DOS apps don't get that much free space). Anyways, it seemed to speed up compilation by 5% using that instead of the default setting.

> 16). don't multi-include huge .h files in every .C module
If you're recompiling with the same defines (e.g. -DBLAH) for different cpu targets (-march=i586, -march=i686) which need different code generation, you can save time by saving the preprocessing output (gcc -E myfile.c -o myfile.i) [or .ii for C++] and using that as source instead (gcc myfile.i -o myfile.exe). Not a huge speed savings, but much more noticeable on older machines.

> 17). break src into multiple modules and use makefiles
> - avoids redundant recompilation of unmodified routines
On slow machines, you may wish to use -Q to tell you what function is being compiled at that particular moment. Then, if you really wanted, you could rewrite the complex ones or put them in their own separate modules.

> 20). use Ultra DMA driver (UIDE, UDMA, XDMA, XDMA32)
For the record, I'm not sure how necessary that is unless you're doing lots of HD writes. For me, I try to always use a RAM disk to compile stuff. And BTW, JEMMEX w/ UIDE seems no slower than plain XMS (actually faster), but that may be affected by CONFIG.SYS' BUFFERS= etc (i.e. it's very hard to prove that something is faster / better 100% of the time).

> 23). avoid (slow!) virtual memory (CWSDPMI) by freeing up RAM if
> available
Apparently, just running "HDPMI32" takes less RAM than "HDPMI32 -r" (+3 MB).

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22049 Postings in 2034 Threads, 396 registered users, 255 users online (1 registered, 254 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum