Mail Archives: djgpp/1995/08/06/22:14:39
In article g84 AT news DOT irisa DOT fr, ecorvell AT irisa DOT fr (Erwann Corvellec) writes:
> Well, I didn't intended to be arrogant at all !
> As I said in my post I was disappointed...
[snip]
> 22 bytes... ;)
> Maybe you don't know what size optimization means ???
>
> Erwann Corvellec.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Student & coder on PC (ASM, C, C++) & fond of LINUX V1.4 ;-D
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Erwann, read what you wrote again. You *are* arrogant, so don't be so surprised
if people get pissed.
And about compilers and their code: When I first started to use gcc on a unix
system, I too was surprised how big some small test program could be, especially
when using C++ iostream instead of printf.
But when I measured speed instead of size I got deeply impressed. Gcc code was
always much faster than all other compilers I tried. And as others have pointed
out already, the size overhead you have found is constant, and will mean nothing
in a real program (as opposed to hello world ones).
I regard myself as quite good at code optimization and I can tell you that in
9 out of 10 times, speed is the goal, not space. And since I started to use gcc,
I have not have to resort to assembler once, not even in the Doom-like graphical
engine I currently work on. Looking at the assembler output, and maybe re-arrange
things slightly to help the compiler making better optimization choices is almost
always enough to make the compiler eventually come up with code as good as if I
had hand-assembled it.
I have used djgpp only a few weeks now, so I'm far from an expert. But I have no
reason to beleive that djgpp have very different characteristics than unix gcc.
And that means excellent.
Mats
- Raw text -