Mail Archives: djgpp/1996/02/25/16:36:24
> - 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.
- Raw text -