X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-bounces using -f From: Charles Sandmann Newsgroups: comp.os.msdos.djgpp Subject: Re: TurboC vs DJGPP in efficiency. Date: Mon, 18 Feb 2002 14:59:30 CST Organization: Rice University, Houston TX Lines: 58 Message-ID: <3c716b32.sandmann@clio.rice.edu> References: <20020218122544 DOT 16460 DOT qmail AT web20805 DOT mail DOT yahoo DOT com> NNTP-Posting-Host: clio.rice.edu X-Trace: joe.rice.edu 1014067054 26191 128.42.105.3 (18 Feb 2002 21:17:34 GMT) X-Complaints-To: abuse AT rice DOT edu NNTP-Posting-Date: 18 Feb 2002 21:17:34 GMT X-NewsEditor: ED-1.5.9 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com > TurboC needs a lot less compile time for the same > file(10 times less approx.) , and it is also a > FASSSTER environment when you compare it to RHIDE. > It also uses a lot less memory. > > ¿Why? ¿So high is the price we must pay for 32-bit > programming? More recent versions of GCC have been obsessed with getting every tiny fraction of the potential performance possible. Each new version has added optimizations which take memory to perform. A 386 will not benefit from many of these optimizations, and would run acceptably with an older version of GCC. If you don't need new features, you might consider finding the oldest version of the tools you can find. They tend to consume much less memory (which is your biggest challenge). > I suppouse that efficiency is not one of the targets > for gcc compiler. It assumes that run time efficiency is all that is important and that compile/build performance is not important. This has been the case with every release of GCC I can remember, since the 1.9 release days. > I'm very happy with DJGPP, but only when I try to use > it in my old 386 I think that maybe it is better to > program in TurboC in that environment. If developing small programs which easily fit in 64Kbytes, I would agree. If you need to move outside the small memory model and start messing with ugly "far" pointer extensions, then you should stick with a 32-bit compiler. Code portability is important - well written code will run fine on multiple platforms - and DJGPP helps encourage portability. > My 386 has only 2MB memory, perhaps it is the worst > environment where DJGPP has runned in. ;-) During V2.00 development I used to routinely test on a 1Mb 386SX system. Compiles were still slow, but bearable. With only 2Mb of memory you might need to tune your CWSDPMI settings to maximize DPMI memory; there is also a balance between disk cache and DPMI memory which you would need to evaluate. Since conventional memory can be used as DPMI memory in situations such as yours, it's important to unload as many DOS programs/drivers/TSRs as possible. Avoid using EMM386 if possible for better performance. I would suggest with newer GCCs you would want to use CWSPARAM to modify "Minimum Application memory before 640K paging" to be 2048Kb (so your system would always page in the 640K region). This might increase your DPMI memory from 768K (assuming a 256K cache) to 1200K. Such a large percentage increase might improve compile performance. This, combined with older GCC and binutils and you might find 32-bit programming much more fun.