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, 20.06.2008, 00:17

We all love GCC, and this topic is definitely not meant to annoy them or detract from their hard work. But, it needs to be mentioned that GCC speed can be slower than necessary if not used properly. Here are a few comments (mostly DOS-oriented, surprise surprise):

First of all, there's a comparison (not by me) done for compiling the GNU/Linux kernel 2.6.14 using 2.95.3, 2.96 (unofficial RedHat patch, 3.x prerelease?), and 3.4.5. See here for the details ("So, GCC 3.4.5 is about 12% faster than 2.96, and about 47% slower than 2.95.3.").

N.B. DJGPP 2.03p2 (DJDEV203) works around some NTVDM bugs in Win XP etc., and my attempts to try older GCCs (e.g. 2.8.1) were not successful (GPFs). The oldest GCC that seems to work fine (b/c recompiled via 2.03p2) is GCC 2.95.3 (Dec. 2001). I'm sure you could recompile 2.8.1 or 2.7.2.1 if you really wanted to further compare speeds. (Of course, 2.7.2.1 doesn't support any Pentium optimizations, and 2.95.3 only can do MMX, nothing newer.)

I tried to find various ways to speed up GCC. Some are more esoteric (or unusable in DOS, at least), and some I didn't test myself (or much at all), so take it with a grain of salt. Nevertheless, I hope it enlightens somebody:

1). "-O0" (or -O2 instead of -O3) [older -O2 is as fast as newer's -O0)
2). older version (e.g. 2.95.3 or 3.4.4) [old is always less standard compliant, e.g. no decent C99 support]
3). distcc (e.g. under Cygwin via cross-compiler: e.g. 3.4.x w/ 3.4.x on 2 PCs)
4). run without too many background services, processes, etc. (pure DOS? ;-)
5). decent-sized cache loaded (UIDE, LBACACHE)
6). fully-defragged HD (full optimization w/ name sort)
7). (FAT only) "upx --best .../*.exe"
8). (NTFS only) "upx -d .../*.exe"
9). "-mtune=i686" (faster than DJ's default "-mtune=pentium", on a P4 at least)
10). recompile GCC + BinUtils w/ newer GCC (and/or using something like
"-march=pentiumpro -mtune=i686" or "-mtune=generic" or "-march=native"
or similar)
11). set TMPDIR= to moderate-sized RAM disk
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)
13). don't use "-v"
14). (no idea if this is possible with DJGPP): precompiled headers??
15). DOSBox (not optimal): turn up frameskip very high
- don't need it when all you're using is cmdline apps !
- you need multi-Ghz in order to emulate a 486, so this is quite slow!
16). don't multi-include huge .h files in every .C module
17). break src into multiple modules and use makefiles
- avoids redundant recompilation of unmodified routines
18). use MinGW's "make -j2" under Win32 (but somewhat incompatible syntax vs. DJGPP's make, i.e. no DOS long cmdline support)
19). cross-compile from Win32 or Linux or *BSD, etc. (faster w/o BIOS ??)
- BTW, FreeDOS seems noticeably faster than MS- or DR-DOS, in some cases
20). use Ultra DMA driver (UIDE, UDMA, XDMA, XDMA32)
21). put %DJDIR%\BIN first in %PATH%
22). if no cache loaded, increase BUFFERS= in CONFIG.SYS
23). avoid (slow!) virtual memory (CWSDPMI) by freeing up RAM if available
- much slower using this + RAM disk than w/ no swapping and no RAM disk
24). run under V86 mode (NTVDM, DOSEMU, VMware??)
- much faster than full cpu emu (QEMU, DOSBox)

Post reply
 

Complete thread:

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