Xref: news2.mv.net comp.os.msdos.djgpp:1421 From: Charles Sandmann Newsgroups: comp.os.msdos.djgpp Subject: Re: Date: Sat, 24 Feb 1996 11:42:22 CST Organization: Rice University, Houston, Texas Lines: 36 Message-ID: <312f4dfe.sandmann@clio.rice.edu> References: <1996Feb23 DOT 135603 AT zipi DOT fi DOT upm DOT es> Reply-To: sandmann AT clio DOT rice DOT edu NNTP-Posting-Host: clio.rice.edu To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp > - I heard people complaining about DJGPP 2.0 being *much* slower than > 1.112 (I mean the generated code, not the compile time). Properly configured, the speed of CPU intensive functions is dependent on the compiler (2.6.3 vs 2.7.2) so may be better or worse. I typically see 2.7.2 to be faster, but one optimization was disabled by default which may slow some code down. You can change this in your lib/specs file if you know your code is OK with this option. I have 2.6.3 built in a manner which you can say "gcc263" to get the old compiler (built with V2 release) which I use to do comparisions. I guess I could put this someplace (about 2Mb of binaries) if anyone is interested. I/O speed is faster under V2, since there are less mode swaps and bigger buffers. So overall, V2 should be faster than V1.x, and if not, it's just a tuning issue. > - I heard too that large compiles of C++ sources bomb DJGPP 2.0, this due > to a bug in CWSDPMI (I think...) There is a bug (and a fix) for CWSDPMI which causes some large C++ programs to puke. There are also problem in stack sizing (default 256K) for both C and C++ programs if they are too big. The stack sizing is any easy one - just stubedit cc1.exe and cc1plus.exe to be 512K instead of 256K if you have trouble compiling big images. I have an image which behaves much like go32-v2 which I will probably put someplace soon which tells you how much stack you have used in an image. You can take the cpp output and feed to cc1/cc1plus to see how much stack you need and tell if you are too close to the edge. I use it to monitor the stack usage in some images I distribute, and since they use less than 32K of stack, I can easily stubedit my default stack to 64K in those images, and they run much more comfortably on small memory machines.