DOS ain't dead

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)

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

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

Is there some speed comparison of CWSDPMI vs HDPMI? I think he was talking about using virtual memory (swapping) which AFAIK HDPMI doesn't support at all. So if we compare speed when not paging?

---
DOS gives me freedom to unlimited HW access.

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

> > > 23). avoid (slow!) virtual memory (CWSDPMI) by freeing up RAM
> >
> > using HDPMI32
>
> Is there some speed comparison of CWSDPMI vs HDPMI? I think he was talking
> about using virtual memory (swapping) which AFAIK HDPMI doesn't support at
> all. So if we compare speed when not paging?

I haven't tested speeds, so I can't say for sure. But even if it ran faster on a 586, it might not run faster on newer cpus (e.g. AMD64 or Core 2). It's very complicated to optimize for several (micro?-)architectures.

Swapping to HD is very slow, obviously moreso than using actual RAM. This is why RAM disks are a good idea (RAM speed > HD speed). And you can disable CWSDPMI swapping by using "lh cwsdpmi -p -s-" (or permanently via CWSPARAM or whatever).

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

Not every app actually needs to be optimized, esp. stuff that only runs for like a second or two. Besides, the faster modern cpus get, the less noticeable it is for some minor stuff. Anyways, it's -O1 (aka, -O) that is officially recommended if you want fast optimization without long compile times. And also, you shouldn't optimize much (if at all) when developing / debugging because it makes it that much harder (esp. with -fomit-frame-pointer, which makes debugging almost impossible).

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

Even newer versions have bugs (regressions). I'm just saying, some apps were written back when those "old" versions were modern and worked fine with them. In those cases, I don't think it's "bad" to use them. If you need better C++ support or C99 or Athlon64 optimizations, of course you're gonna have to upgrade.

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

Well, I can't say for sure how unstable compiles would be on that. But it's majorly not recommended anyways because it's so ultra slow.

> > 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'm not sure when this is a good idea or not, esp. re: single core cpus and what number is appropriate for what situations (-j4?). But hey, it's worth noting. Too bad nobody ever implemented DR-DOS multitasking support into any make variant (that I know of, anyways).

> I haven't tested speeds, so I can't say for sure. But even if it ran
> faster on a 586, it might not run faster on newer cpus (e.g. AMD64 or Core
> 2). It's very complicated to optimize for several (micro?-)architectures.

Well, I did a single test on ye olde P166 (no MMX, F/M/S: 5/2/C) w/ total 32 MB RAM, running DR-DOS 7.03, using UIDES (5 MB) and %TMPDIR% pointing to a 3 MB RAM drive. And I tried recompiling TDE 5.1v with "-O0" (GCC 3.4.4, DJGPP 2.04). And yes, I ran "cc" (clear cache) before each compile. "lh cwsdpmi -p -s-" and "lh hdpmi32 -r" were used before beginning. (Note that TDE 5.1v has a fair amount of separate .C files to compile, so I figured this was a fair way to test since a single-file .CPP didn't seem to show any difference.)

CWSDPMI r5 "testing" (2002): Elapsed time: 166.700 seconds (0:02:46.700)
HDPMI32 from latest HXRTD.ZIP: Elapsed time: 160.930 seconds (0:02:40.930)

So, yes, HDPMI32 is faster (approx. 4%). However, it may be the opposite (by accident) on a PII, P4, AMD64, Core 2, etc. More testing welcome.

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

> gold
> linker (ELF only) which claims to be 5x faster (self-admittedly its
> main advantage)??

So they can't speed things up that aren't bottlenecks without deserving criticism?

> So they can't speed things up that aren't bottlenecks without deserving
> criticism?

Eh? That wasn't even the slightest bit of criticism from me, just saying that despite what some people think ("linkers are fast enough"), others spend time speeding them up (as much as five times for large C++ programs, in this case). I'm all for more speed (even if it is x86/x86-64 ELF only, for now).

> CWSDPMI r5 "testing" (2002): Elapsed time: 166.700 seconds
> (0:02:46.700)
> HDPMI32 from latest HXRTD.ZIP: Elapsed time: 160.930 seconds
> (0:02:40.930)
>
> So, yes, HDPMI32 is faster (approx. 4%). However, it may be the opposite
> (by accident) on a PII, P4, AMD64, Core 2, etc. More testing welcome.

Good . However, a compiler is not a good tool to test the speed of DPMI hosts, because you can't tell how much of the total time is spent with internal tasks.

---
MS-DOS forever!

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

> > gold
> > linker (ELF only) which claims to be 5x faster (self-admittedly
> its
> > main advantage)??
>
> So they can't speed things up that aren't bottlenecks without deserving
> criticism?

I've seen GNU LD linking a 6MB file taking over 40 minutes on a 1.6GHz Core Duo (not core 2) with 1 GB.

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

> Some (admitted only sideways) related info why gcc is fairly slow:
>
> (news://comp.compilers URLs)
>
> Disclaimer: yes those are posts by me.

When searching through Google for GCC tips, I found those and already read 'em. Yes, we know, GCC ain't Delphi. And it's actually the tree RTL backend optimizer (or whatever) that now seems to be the main slowdown (the whole advantage of 4.x over 3.x). Try compiling with "-Q -v" if you're curious.

Anyways, speaking of faster compiles (even though it isn't DOS-oriented), there's always TCC (recently updated to 0.9.24 in April, but I didn't notice until today, go figure). The Win32 port is even smaller now! Granted, it's C only (and needs MSVCRT, blech), but it's still very cool.

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

The NASM and YASM developers cross-build the DOS releases. I can only guess that a). Windows is less aggressive re: caching (although Vista stepped it up some more), and b). GCC/GNU are very very POSIX-oriented, and Win32 has to emulate some of that since it doesn't have it natively, therefore running slower than it would be. Plus, GNU/Linux just by default seems to get every freakin' genius coder working on it (unlike closed src MS). At least we get Japheth.

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

Maybe more background crud running?? I dunno, try running "msconfig" and stop some of those dumb AcroRead, Jusched, etc. bogus speedup (i.e. slowdown) startups. Then again, you're savvier than me, so you probably knew that.

> > 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)
>
> Maybe more background crud running??

No, IMHO simply not optimized enough for program starting. It is no different on a clean windows, and it has always been. The old Unix programmers rule: Windows slow process, fast thread, (free) Unix fast process, slow thread. However this has been changed with NPTL.

I used to testdrive new NT servers at work by doing a FPC build cycle, systems with quite some I/O bandwidth, but they hardly could get by a normal system running Linux. (FreeBSD 3.x wasn't that fast with I/O, that only got in the same magnitude in 4.x times)

So disk caching probably also. In the old days when performance still mattered, building on a scratch partition with "noatime" set could also do wonders.

I recently actually found a registry key on Windows that did the same for NTFS, but only globally. Unfortunately not per filesystem as on Unix.

> > Some (admitted only sideways) related info why gcc is fairly slow:
> >
> > (news://comp.compilers URLs)
> >
> > Disclaimer: yes those are posts by me.
>
> When searching through Google for GCC tips, I found those and already read
> 'em. Yes, we know, GCC ain't Delphi. And it's actually the tree RTL
> backend optimizer (or whatever) that now seems to be the main slowdown
> (the whole advantage of 4.x over 3.x). Try compiling with "-Q -v" if
> you're curious.

I included a header in a trivial program, and preprocessing was 50%. So this kinds of benchmarks depend heavily on how your headers are organized. (the notorious "one big header per project that includes everything necessary problem".)

Still it is an interesting option, I'll see if I can compile something like binutils that way.

> Anyways, speaking of faster compiles (even though it isn't DOS-oriented),
> there's always TCC (recently
> updated to 0.9.24 in April, but I didn't notice until today, go figure).
> The Win32 port is even smaller now! Granted, it's C only (and
> needs MSVCRT, blech), but it's still very cool.

I still work full time with Delphi. If something usuable beats that with an untweaked setup, let me know

> So disk caching probably also. In the old days when performance still
> mattered, building on a scratch partition with "noatime" set could also do
> wonders.

I've heard both "noatime" and "relatime" can help, but it seems to matter more what filesystem is in use (since Linux supports so many). However, that's something no one seems to agree upon (ext2? XFS? JFS? Reiser??). See here.

P.S. I forgot to mention earlier, -pipe supposedly speeds GCC up a lot too (although not support on DOS).

> I've heard both "noatime" and "relatime" can help, but it seems to matter
> more what filesystem is in use (since Linux supports so many). However,
> that's something no one seems to agree upon (ext2? XFS? JFS? Reiser??).
> See

noatime helps on any file system that supports storing access times. That goes in general for file IO, not just for compiling.

It's because when you compile, you may be reading 1000 files -- each read will then involve a write, which is much more expensive than a read. This adds up; disabling all these writes saves a little bit of time and disk wear.

> P.S. I forgot to mention earlier, -pipe supposedly speeds GCC up a
> lot too (although not support on DOS).

And if you're technically inclined (or really bored), you may find this interesting: Speedup areas (GCC Wiki)

> > So disk caching probably also. In the old days when performance still
> > mattered, building on a scratch partition with "noatime" set could also
> do
> > wonders.
>
> I've heard both "noatime" and "relatime" can help, but it seems to matter
> more what filesystem is in use (since Linux supports so many). However,
> that's something no one seems to agree upon (ext2? XFS? JFS? Reiser??).

General unix. I know it best from ext2 and ufs (the latter under FreeBSD, my primary *nix)

> P.S. I forgot to mention earlier, -pipe supposedly speeds GCC up a
> lot too (although not support on DOS).

Yes, but configure adds it automatically if possible or the default make.conf did, don't know exactly anymore, but iirc it didn't need to be set manually on *nixes.

(Sorry in advance for bumping an "old" thread, if you care.)

> I still work full time with Delphi. If something usuable beats that with
> an untweaked setup, let me know

Doesn't Delphi use an incremental linker? At least, Borland C Builder 5.5 supposedly does, and things like that (which MS also uses, but not GNU?) greatly speed up things.

BTW, did you know that the following IDEs were all written in Delphi / FreePascal? (Ah, the irony.) Wonder why.

Dev-C++
Open Perl IDE
(unreleased) FreeBASIC Elite

> (Sorry in advance for bumping an "old" thread, if you care.)
>
> > I still work full time with Delphi. If something usuable beats that
> with
> > an untweaked setup, let me know
>
> Doesn't Delphi use an incremental linker?

Afaik no (or at least not in older versions) The binary on disk is really new. But since the whole system (compiler and linker) is (very) integrated, it could cache maybe the to-be linked parts, so it only has to do a few fixups.

> At least, Borland C Builder 5.5
> supposedly does, and things like that (which MS also uses, but not GNU?)
> greatly speed up things.

GNU has nothing beyond -pipe in the speed department afaik. Not even precompiled headers. (though there is work about that being done)

> BTW, did you know that the following IDEs were all written in Delphi /
> FreePascal? (Ah, the irony.) Wonder why.

It works (tm). Probably also because with synedit there is a general purpose IDE code editor component that is easily customized. So you link that up with GDB-MI, add a highlighter (if not already there, synedit has two dozen already) and you almost have an IDE.

> Dev-C++

Yes I know this one. At least I knew the pascal version. Getting that to compile with Lazarus is still a long term objective of mine. (I was getting pretty close during the last attempt btw). Will remain windows only though, lots of use of special widgets.

> Open Perl IDE

Dead, last release 2003

> (unreleased)
> FreeBASIC Elite

There are lots of ides for freebasic, but they most seem to be one-man projects that die after the author runs out of steam.

Personally I think the cool thing with Lazarus is that it actively maintained for over ten years, and the multiplatform RAD aspect.

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