DOS ain't dead

> GCC speed can be slower than necessary if not used properly

> 4). run without too many background services, processes, etc. (pure DOS?



> 5). decent-sized cache loaded (UIDE, LBACACHE)

see 11. below

> 8). (NTFS only) "upx -d .../*.exe"

NTSC4DOS rocks

> 11). set TMPDIR= to moderate-sized RAM disk

Most likely the best idea in your list

> 20). use Ultra DMA driver (UIDE, UDMA, XDMA, XDMA32)

RAM is better, see 11. above

> 23). avoid (slow!) virtual memory (CWSDPMI) by freeing up RAM

using HDPMI32

> 24). run V86 mode (NTVDM, DOSEMU, VMware??) faster than full emu (QEMU, DOSBox)

Natively ?

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> 1). "-O0" (or -O2 instead of -O3) [older -O2 is as fast as newer's -O0)

BAD. The time you're saving compiling is not worth all the time lost in an application that is now not optimized at all. Use -O2, not -O3, which may cause instability.

> 2). older version (e.g. 2.95.3 or 3.4.4) [old is always less standard
> compliant, e.g. no decent C99 support]

These compilers may also contain bugs, while rare.

> 4). run without too many background services, processes, etc. (pure DOS?

Multitasking OSes are better at compiling.

> 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!

BAD. Avoid compiling in emulators, especially buggy ones :p

> 18). use MinGW's "make -j2" under Win32 (but somewhat incompatible syntax

This is partially what I was referring to with my response to #4.

> 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.

I'm also not sure if -Wall makes any difference or not (didn't seem to, or at least not consistently). And using stubedit to increase the transfer buffer may (or may not) help too, I dunno, didn't really delve into that area.

BTW, I forget where I heard it, but somebody recently said a linker was not the tool that usually takes the most time and isn't worth worrying about. However, if that were true, then why did GNU Binutils recently merge in the gold linker (ELF only) which claims to be 5x faster (self-admittedly its main advantage)??

> 18). use MinGW's "make -j2" under Win32 (but somewhat incompatible syntax
> vs. DJGPP's make, i.e. no DOS long cmdline support)

For the 386+ Dos lovers:

Patch make and do the same under DV/X ? Afaik the DV/X api allowed spawning new dosboxes.

> 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:

Another note, a real *nix will kill mingw or cygwin in speed. I sometimes compile cross-binutils on mingw and it takes 10-20 minutes, something that is sub minute on linux/freebsd.

It is possibly related to the rather heavy process creation time on Windows (and configure + the GNU system being overly fragmented into multiple binaries, with e.g. FPC which integrates more into one binary it is less pronounced)

Some (admitted only sideways) related info why gcc is fairly slow:

http://compilers.iecc.com/comparch/article/03-12-007

http://compilers.iecc.com/comparch/article/02-07-128

Disclaimer: yes those are posts by me.

> 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).